ring deployment architecture
· 2 min read
there are many ways to roll out a new product, feature or even a new version of an existing product to the users. but orgs often face challenge when the scale of users is very high, which they dont trust the tests run in local or even staging environments.
in this blog, lets understand one of the ways to roll out a new version/feature to the large number of users in a safe and reliable way with minimal blast radius.
Ring Deployment
it is a progressive rollout strategy, where you roll out the new version/feature in rings - which is more of controlled groups that expand in size.
basically,
canary -> early adopters -> wider groups -> ga (general availability)
each ring is more of a safety buffer, if something goes wrong/breaks, it can be rolled back to previous ring or stop at that ring - preventing full scale outages.
why do orgs use it?
a few reasons:
- reduce the blast radius of the new feature/version
- observe real world usage patterns
- evaluate the impact and quality
- testing the performance at scale
example ring structure:
| Ring | Description | Size |
|---|---|---|
| Ring 0 | Internal team / staging | ~0.1% |
| Ring 1 | early adopters / beta users | ~1% |
| Ring 2 | private preview | ~5–10% |
| Ring 3 | public preview | ~20–50% |
| Ring 4 | ga (general availability) | 100% |
rings can be configured based on the risk level and scale of the users. fox example, you can multiple rings for internal testing itself. you can also have multiple rings for different regions, different languages, different industries, etc.
Under the hood, how does it work?
4 major components:
- routing layer
- decides which ring to route the request to
- deployment orchestrator
- manages the deployment of the new version/feature to the rings and controls how many instances of each version exist.
- feature flags
- stores the roll out % for each ring
- kill switch for immediate disable
- monitoring and rollbacks
- observes the metrics and rolls back if thresholds break.
few rollback metrics whenever using ring deployment (*depends on product):
error rate
- can be API errors
- model failures (language models)
- timeouts
performance
- latency (p99, p95)
- resource usage
- cold start time
final thoughts:
ring deployment gives orgs more control over the rollout and very less overhead of human errors, by gradually expanding the rollout catching the issues, regressions very early.