Implementing a Feature Flag System
Fast recall
Quick revision
Core answer
Whether you understand feature flags as a deployment and experimentation tool beyond simple if/else switches, including targeting rules, gradual rollouts, and kill switches.
Treating feature flags as permanent code switches rather than temporary mechanisms with a defined lifecycle, leading to flag debt.
Mention using a dedicated feature flag service (LaunchDarkly, Unleash) rather than database booleans, discuss targeting rules for user segments, percentage rollouts, and the importance of flag cleanup policies.
Interview-ready guide
Interview answer
Feature flags decouple deployment from release — you deploy code to all instances but only enable it for a controlled subset of users, which means you can release to 0.1% of users, validate in production, and roll out gradually without repeated deployments.
Why feature flags matter
- Without feature flags, deploying a new feature is the same event as releasing it — all users see it immediately; if the feature has a bug, every user is affected and the only fix is a rollback deployment
- With feature flags, you deploy the code (zero risk — the flag is off), then enable it for 1% of users (minimal risk), expand to 10% (validate with more data), then 100% — each step is a configuration change, not a deployment
Implementation options
- LaunchDarkly and Unleash are dedicated flag services — they provide a UI for managing flags, targeting rules (user segment, user attribute, random percentage), A/B testing, and an SDK that evaluates flags at runtime
- Simple in-house implementation: store flag names and percentages in a database or Redis; evaluate on each request by hashing the user ID with the flag name to get a consistent 0-100 value; enable if below the threshold — this gives consistent user experience (the same user always sees the same variant)
Implementation in Spring Boot
- A service class that evaluates flags:
flagService.isEnabled("checkout-v2", userId)returns true/false; the calling code wraps the new path in an if-block - Avoid flag proliferation — each flag is technical debt; plan to remove flags after full rollout; a flag that persists for more than 3 months is a smell that the rollout is stalled or the flag was never intended to be temporary
Operational flags vs user-facing flags
- Operational flags (circuit breakers, kill switches): "disable the recommendation engine if it's slow" — these need instant evaluation, often without user context; store in Redis for sub-millisecond reads
- User-facing flags: A/B testing, gradual rollouts — these require consistent user targeting and analytics on which variant users saw
Implementing a Feature Flag System
Direct Answer
Use a dedicated flag service like LaunchDarkly or Unleash; implement flags with targeting rules and percentage rollouts; define a flag lifecycle with mandatory cleanup dates to prevent flag debt.
Common Mistakes & Pitfalls
Treating feature flags as permanent code switches rather than temporary mechanisms with a defined lifecycle, leading to flag debt.
Check your understanding
Answer these without looking back at the article.
- How do you test code behind a feature flag?
- What is the difference between a feature flag and a configuration property?
- How do you handle database schema changes with feature flags?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.