Feature Flags & Rollouts

"Deploy a new feature to all 100M users at once" is asking for a 3am incident. Feature flags let you separate code deploy from feature release: ship the code dark, then turn it on for 1% of users, watch metrics, ramp to 10%, 50%, 100%. If anything goes wrong, flip it off — no rollback, no redeploy.

Modern continuous deployment depends on this. Stripe deploys hundreds of times per day; nothing reaches all customers without a flag-controlled rollout.

Code path:

if (flags.isEnabled("new-feed-ranker", { user_id, country, plan })) {
  return newRanker(user);
} else {
  return legacyRanker(user);
}

Inside isEnabled:

1. Look up the flag's rules (cached locally; refreshed every few seconds).
2. Apply targeting: "enabled for premium users in EU" → check the context.
3. Apply percentage rollout: hash the user_id deterministically into a 0–99 bucket; if bucket < rollout%, return true.
4. Cache the result.

Critical: the bucketing is deterministic per user. Same user always gets the same answer until rollout% increases. Otherwise users would flip in/out of the experience randomly per request.

• Default to OFF for new flags. Code that hasn't been tested in prod stays dark.
• Test both branches in CI. Run your suite with the flag on and off.
• Time-bound release flags. Track them in a registry; flags older than 60 days get reviewed and deleted. Otherwise you accumulate dead branches.
• Monitor by flag. Each flag should expose metrics: enabled-vs-disabled performance, error rate per branch. Alerts when one branch regresses.
• Make rollback instant. Flag changes propagate in < 60s. If you have to redeploy to disable a feature, your flag system is broken.

Beyond simple percentage rollouts, modern teams use a ladder:

1. Internal dogfood — flag enabled only for company employees (filter by email domain). Catch egregious bugs.
2. Beta cohort — opt-in users / specific accounts. Real-world feedback at low risk.
3. Canary deploy — code rolled out to 1 server out of N. Hardware-level isolation. If that one server crashes, only its share of traffic is affected.
4. 1% percentage rollout — flag bumps from 0% to 1%. Watch error rate, latency, business metrics. Hold for an hour.
5. 10% → 50% → 100% — over hours or days. Each step is a checkpoint.
6. Cleanup — once at 100% for a stable period, remove the flag and the legacy branch. Avoid permanent flag debt.

Sophisticated platforms (LaunchDarkly, Split, Optimizely) automate the ladder: define a rollout policy, the platform advances rollout% based on guardrail metrics. Halt automatically if anomalies detected.

News feed gates new ranker rollouts via flags + A/B test. E-commerce uses flags for checkout flow experiments + kill switches per payment provider. Notification system gates new channel integrations.