We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A company could only release new features during scheduled maintenance windows, typically 2 AM on Saturday. Why? Because deployment and release were the same thing. Deploying code meant every user immediately got every new feature. If something broke, the only option was to redeploy the old version, which meant another maintenance window.
Feature flags decouple deployment from release. You deploy code with new features hidden behind flags. The code is in production but inactive. When you are ready, you flip the flag. No deployment needed. If something goes wrong, you flip it back. No rollback needed. The 2 AM deploy window becomes unnecessary because deployments are safe. They do not change user-facing behavior until you decide to enable features.
GitHub deploys to production 20+ times per day and uses feature flags for every new feature. They call it "ship code to production on day one, enable it when it's ready." Facebook's Gatekeeper system evaluates billions of flag checks per day across their entire platform.
| Flag Type | Purpose | Lifetime | Example |
|---|---|---|---|
| Release flag | Hide incomplete features in production | Days to weeks | show_new_checkout |
| Experiment flag | A/B test variations | Weeks to months | checkout_button_color |
| Ops flag | Kill switch for features under load | Permanent | disable_recommendations |
| Permission flag | Enable features for specific users/roles | Permanent | enable_admin_panel |
Progressive rollout, the safe way to release:
| Step | Who Sees It | Duration | What to Watch |
|---|---|---|---|
| 1 | Internal team only (dogfooding) | 1-3 days | Functionality, UX feedback |
| 2 | 1% of users (canary) | 1 day | Error rates, p99 |
| 3 | 10% of users | 2-3 days | Conversion metrics, support tickets |
| 4 | 50% of users | 1-2 days | Load impact, business metrics |
| 5 | 100% of users | Permanent | Steady-state monitoring |
At each step, monitor error rates, latency, and user feedback. If anything degrades, roll back the flag to the previous step.
Feature flag services: LaunchDarkly ($25/seat/month, the market leader), Flagsmith (open-source), Statsig (experiment-focused), Unleash (self-hosted). These provide targeting rules (user segments, percentages), analytics, and audit trails.
The tech debt warning: Feature flags that are never cleaned up become dead code branches. Netflix found that 90% of their flags should have been removed within 2 weeks of full rollout. Every flag should have an owner and an expiration date. Old flags should be removed within 2 weeks of 100% rollout.
When NOT to use feature flags. For changes that do not affect user-facing behavior (refactoring, dependency updates, performance optimizations). Wrapping every code change in a flag adds unnecessary complexity.