The Light Switch Analogy
A light switch:
- Flip on: Light turns on
- Flip off: Light turns off
- No rewiring needed
Feature flags are light switches for code. Turn features on or off without deploying new code.
if (featureEnabled("new-checkout")) {
showNewCheckout();
} else {
showOldCheckout();
}
Switch in dashboard: ON → OFF
No deployment needed!
Why Feature Flags?
Separating Deploy from Release
| Traditional | With Feature Flags |
|---|---|
| Deploy code = Feature is live | Deploy code = Feature is deployed (but OFF) |
| Release when code is ready | Flip flag = Feature is live |
| Rollback = new deployment | Rollback = flip flag OFF |
Deploy anytime. Release when ready.
Key Benefits
| Benefit | How It Helps |
|---|---|
| Gradual rollouts | 1% → 10% → 50% → 100% of users |
| Instant rollback | Problems? Flip to OFF immediately |
| A/B testing | 50% see version A, 50% see version B |
| Kill switch | Disable problematic features instantly |
| Targeting | Show to specific users or segments |
| Ship faster | Deploy incomplete features (hidden) |
Types of Feature Flags
| Type | Purpose | Lifespan | Example |
|---|---|---|---|
| Release | Control when feature goes live | Short (remove after rollout) | New checkout UI |
| Experiment | A/B testing | Medium (duration of test) | Blue vs green button |
| Ops | Operational control | Permanent | Disable under high load |
| Permission | Access control | Permanent | Premium features |
Release Flag Example
Week 1: Ship new UI, flag OFF (hidden)
Week 2: Enable for employees only
Week 3: Enable for 10% of users
Week 4: Enable for 100%
Week 5: Remove flag from code
Experiment Flag Example
| Variant | Users | Goal |
|---|---|---|
| A (blue button) | 50% | Measure conversions |
| B (green button) | 50% | Measure conversions |
Winner becomes the default!
How Feature Flags Work
The Flow
1. Code checks flag → "Is 'new-feature' enabled?"
2. Flag service responds → true/false
3. Code executes → Shows feature (or not)
4. Dashboard controls → Toggle without deploy!
Targeting Options
| Target Type | Example | Use Case |
|---|---|---|
| Everyone | All users | Full rollout |
| Percentage | 10% of users | Gradual rollout |
| User ID | user_123, user_456 | Beta testers |
| Attribute | country = "US" | Geographic rollout |
| Combined | 10% of premium users in EU | Complex targeting |
Common Use Cases
1. Gradual Rollout
| Week | % Users | Action |
|---|---|---|
| 1 | 1% | Monitor metrics closely |
| 2 | 10% | Looking good, expand |
| 3 | 50% | Watching for issues |
| 4 | 100% | Full release |
Problem at any stage? Turn OFF immediately.
2. Beta Testing
| User Type | Flag State | Experience |
|---|---|---|
| Beta testers list | ON | See new feature |
| Everyone else | OFF | See current experience |
No separate beta environment needed!
3. Kill Switch
Third-party API acting up?
if (flags.isEnabled("use-backup-api")) {
callBackupAPI(); // Failover
} else {
callMainAPI(); // Normal
}
Toggle in seconds, no deploy needed.
4. A/B Testing
| Metric | Variant A | Variant B | Winner |
|---|---|---|---|
| Conversion rate | 3.2% | 4.1% | B |
| Cart abandonment | 45% | 38% | B |
Data-driven decisions!
Feature Flag Platforms
| Tool | Type | Best For |
|---|---|---|
| LaunchDarkly | Enterprise SaaS | Complex targeting, scale |
| Split | Enterprise SaaS | Experimentation focus |
| Flagsmith | Open source | Self-hosted control |
| Unleash | Open source | Self-hosted, feature-rich |
| ConfigCat | Simple SaaS | Small teams, quick setup |
Build vs Buy Decision
| Needs | Recommendation |
|---|---|
| Simple on/off for a few features | Build (if/else with database) |
| Targeting, experiments, analytics | Buy (LaunchDarkly, Split) |
| Enterprise scale, compliance | Definitely buy |
Feature Flag Lifecycle
CREATE → DEVELOP → TEST → BETA → ROLLOUT → RELEASE → CLEANUP
↓ ↓ ↓ ↓ ↓ ↓ ↓
Add flag Devs Enable Enable 1%→10%→ 100% Remove
(default can for for 50%→100% rollout flag from
OFF) enable QA beta code
locally env users
Cleanup is CRITICAL - old flags pile up!
Best Practices
1. Clean Up Old Flags
| Problem | Solution |
|---|---|
| 100 old flags = confusing mess | Remove flags after full rollout |
| "Is this flag still needed?" | Set cleanup dates when creating |
| Dead code paths | Delete both flag and feature code |
2. Name Flags Clearly
| ❌ Bad | ✅ Good |
|---|---|
flag_123 | enable_new_checkout_ui |
test_feature | experiment_green_signup_button |
Include what it controls and its purpose.
3. Default to Conservative Behavior
| Scenario | Default Behavior |
|---|---|
| Flag evaluation fails | Return OFF (existing behavior) |
| Flag service is down | Use cached value or OFF |
| New feature | OFF until explicitly turned ON |
4. Log Flag Evaluations
Log every evaluation for debugging:
- User ID
- Flag name
- Result (on/off)
- Timestamp
Essential for "Why did user X see Y?"
Common Mistakes
1. Not Removing Flags
Problem: Old flags pile up, code becomes spaghetti Solution: Schedule cleanup as part of feature completion
2. Flag Dependencies
| Flag A | Flag B (requires A) | Result |
|---|---|---|
| ON | ON | Works |
| ON | OFF | Works |
| OFF | ON | Doesn't work |
Document dependencies. Test combinations.
3. Testing Only One Path
Make sure to test both:
- Feature ON path
- Feature OFF path
Both must work correctly!
4. Using Flags for Config
| ❌ Feature Flag | ✅ Configuration |
|---|---|
DATABASE_URL | Environment variable |
API_TIMEOUT=30 | Config file |
enable_new_ui | Feature flag âś… |
Flags are for temporary feature control, not permanent settings.
FAQ
Q: Feature flags vs environment variables?
| Aspect | Env Vars | Feature Flags |
|---|---|---|
| When set | Deploy time | Anytime |
| Change | Requires restart | Instant |
| Targeting | Per environment | Per user |
Q: Do feature flags slow down my app?
Good platforms cache locally. Typical impact is microseconds - negligible.
Q: How do I handle flags in tests?
Set flags explicitly in tests. Don't depend on production flag state.
Q: Client-side or server-side?
| Server-side | Client-side |
|---|---|
| More control | Faster |
| Less exposed | Needs SDK |
| Can hide flag logic | Flag visible in code |
Summary
Feature flags decouple deployment from release, enabling controlled rollouts and instant rollback.
Key Takeaways:
- Toggle features without deploying
- Gradual rollouts reduce risk
- Instant rollback in emergencies
- A/B testing built-in
- Target specific users/segments
- Clean up flags after release!
- Default to OFF for safety
Feature flags give you a "kill switch" for every feature!
Related Concepts
Leave a Comment
Comments (0)
Be the first to comment on this concept.
Comments are approved automatically.