sethdford Feature Flag Design
Using flags to decouple deployment from release; enable gradual rollouts and fast rollback.
Context
You are implementing feature flags. Design them carefully; they add complexity.
Domain Context
- Kill Switch: Instantly disable feature if problematic
- Gradual Rollout: 1%, 10%, 50%, 100%; monitor each stage
- Canary Users: Beta testers; test features early
- A/B Test: Compare two implementations; measure impact
- Audience: Flags can be per-user, per-region, per-segment
Instructions
- Keep Simple: Don't over-engineer; flags add complexity
- Owner: Who owns the flag? Who can toggle?
- Expiration: When should flag be removed? Set date
- Rollout: Gradual strategy; start small
- Monitoring: Track flag usage, errors, impact
- Cleanup: Remove flags after rollout complete
- Config: Flags in code, toggled via server; fast toggle
Anti-Patterns
- Flags everywhere; can't understand code paths
- Permanent flags; accumulate and complicate
- Not monitoring flags; don't know if feature works
- Slow flag propagation; takes minutes to toggle
- Flags without expiration date; forgotten forever
Further Reading
- LaunchDarkly documentation
- Feature flags best practices
- Flickr's approach to feature deployment