Feature-Flag Rollout
Ship code dark, then turn features on for cohorts without redeploying.
StarterPlatform
New functionality ships behind a flag, disabled by default. A flag service controls who sees it -- internal users, a percentage rollout, specific accounts -- decoupling deployment from release entirely.
When to use it
- You want to decouple 'deployed' from 'released' to reduce deploy risk
- Rollout needs to target specific cohorts or ramp gradually without a redeploy
Trade-offs
- Stale flags accumulate as tech debt if not cleaned up after full rollout
- Testing every flag combination in production-like code paths gets combinatorial
Components used
Single-Page AppManaged App ServiceFeature Flags
How it works
- Code ships to production disabled behind a runtime conditional, decoupling deployment from release.
- A flag service decides per request — by user, cohort, percentage or attribute — whether the new path is active.
- Disabling a bad feature is a configuration change taking effect in seconds, with no build or deploy.
Used in the wild
- Trunk-based development, where unfinished work is merged continuously but stays dark.
- Gradual rollouts to internal users, then beta cohorts, then everyone.
- Operational kill switches for expensive features during traffic spikes.
Good to know
- Flags are technical debt with a timer. Every flag doubles the number of code paths, and a codebase with hundreds of stale flags is untestable in combination.
- Knight Capital lost roughly $440 million in 45 minutes in 2012 partly because a repurposed flag activated dormant code on servers that had not been updated.
Related patterns
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
CQRS
Separate models and stores for writes and reads.
Blue-Green Deployment
Run two full production environments, switch traffic between them.
Canary Release
Send a small slice of traffic to the new version before a full rollout.