Feature Flags + Trunk-Based Development: Continuous Deployment Pattern
Fast recall
Quick revision
Core answer
Modern release engineering practices and the connection between branching strategy and delivery cadence
Treating feature flags as just config toggles — missing the targeting, gradual rollout, and kill switch dimensions
Discuss flag debt cleanup, OpenFeature standard, percentage rollouts based on user hashing for stability, and using flags as circuit breakers for failing dependencies
Interview-ready guide
Interview answer
Feature flags solve a structural problem in software delivery: deployment and release are coupled, and that coupling forces teams into long-lived branches and big-bang releases.
The core idea — deploy/release decoupling
- Deployment means shipping a binary to production; release means turning a feature on for users; traditionally these happen together — deploy a feature and users see it instantly
- With feature flags, code merges to main wrapped in a flag; the binary deploys to production with the flag off; users see no change; the team turns the flag on later when ready
- The release moment is now an independent decision, not a build-and-deploy cycle
Why this matters — trunk-based development
- Without flags, half-finished features can't merge to main without breaking production — forcing long-lived feature branches that accumulate merge conflicts
- With flags, a partially-built feature can merge daily behind a disabled flag; integration happens continuously; merge hell disappears
- The whole team commits to main multiple times a day; CI runs on every commit; trunk-based development is unblocked
Operational benefits
- Kill switch: a feature causing errors can be turned off in seconds via the flag service — no rebuild, no redeploy; faster MTTR than any rollback
- Gradual rollout: start a feature at 1% of users, watch metrics, expand to 10%, then 100%; limits blast radius for risky changes
- Targeted rollout: enable for internal employees only, or one geography, or a specific customer for piloting; without a code change
Tooling and standards
- LaunchDarkly is the gold-standard commercial offering; Unleash and Flagsmith are open-source alternatives; OpenFeature is the vendor-neutral SDK standard
- The SDK caches flag values locally, polled from the service every 30 seconds; per-request latency is microseconds; cache misses fall back to a configured default
Watch out for flag debt
- Every flag adds a fork in the code; without cleanup discipline you accumulate hundreds of stale flags; require a ticket to remove every flag once it reaches 100% rollout
- Don't use feature flags for security — they're a delivery mechanism, not an authorization system; use OPA or RBAC for permission checks
Feature Flags + Trunk-Based Development: Continuous Deployment Pattern
Direct Answer
Feature flags decouple deployment (shipping the binary) from release (turning the feature on for users). Code merges to main behind a disabled flag, gets deployed to production, then is gradually enabled (1% → 100%, or per-user, per-region). This eliminates long-lived feature branches, enables continuous deployment of half-finished features safely, and provides a runtime kill switch independent of deployment. Tools: LaunchDarkly, Unleash, Flagsmith, OpenFeature.
Common Mistakes & Pitfalls
Treating feature flags as just config toggles — missing the targeting, gradual rollout, and kill switch dimensions
Check your understanding
Answer these without looking back at the article.
- What is OpenFeature and why does it matter for vendor neutrality?
- How do flag SDKs ensure consistent per-user assignment for percentage rollouts?
- What is flag debt and how do mature teams manage it?
- How do you test code that has many feature flags without combinatorial explosion?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.