Design and Implementation of a Simple Gray Release System

Internet products need rapid iteration while ensuring quality, so a gray release system is designed to control the impact of newly deployed features by routing a portion of user traffic to the new version and allowing quick rollback if problems arise.

The gray release system functions like an A/B testing platform, using configurable strategies to direct traffic to the new system for validation and to revert instantly when issues are detected.

A simple gray release architecture consists of three essential components: a strategy configuration platform that stores gray release rules, an execution program that applies these rules, and a service registry that records service instances with IP, port, name, and version.

Common gray release strategies include traffic splitting based on request headers, cookies, or request parameters such as user UID modulo a percentage, allowing fine-grained control over which users see the new version.

Strategies can be single (e.g., UID, token, IP) or composite, where multiple services are gray‑released together using a tag field to coordinate which requests are routed to which service versions.

Execution control varies by upstream service. When using Nginx, Lua extensions are required to interpret gray strategies, and a locally deployed agent must fetch strategy updates from a configuration platform and gracefully reload Nginx.

For gateway or business logic layers, integrating a configuration platform SDK enables services to receive and apply gray strategies directly without additional proxies.

Complex scenarios include gray‑releasing multiple services in a call chain by tagging requests at the gateway and routing downstream services based on the tag, as illustrated in the accompanying diagram.

When gray‑releasing services that involve data changes, a separate database copy is required because schema differences prevent direct writes to the old database; a dual‑write approach with an MQ ensures full data consistency during migration.

During the gray release, data from both old and new databases should be compared to verify consistency, ensuring that a rollback or full migration does not result in data loss.