Release Engineering: Scenario-Based Questions

Feature flags allow teams to decouple deployment from release. They enable gradual rollouts, A/B testing, and emergency kill switches — but without proper governance, they can cause technical debt or outages.

🎛️ Types of Feature Flags

• Release Flags: Gate new features before full rollout.
• Experiment Flags: A/B tests and user segmentation.
• Ops Flags: Toggle infra or config options at runtime.
• Permission Flags: Enable features by role or plan tier.

🧰 Tools & Platforms

• LaunchDarkly, Unleash, Flagsmith, Split.io.
• Homegrown: Config via DB, Redis, or S3 + reload logic.
• CI/CD integration: flags toggle via GitOps or change pipelines.

🚀 Rollout Strategies

• Targeted rollout (user %, region, team).
• Canary deployment → expand → global enablement.
• Immediate rollback via kill switch on flag.

✅ Best Practices

• Document flags with TTL, owner, and purpose.
• Enforce flag cleanup post-release with linting or audits.
• Log flag evaluations and their effect per request.
• Fail safe: Design flags to default safely on failure or delay.

🚫 Common Pitfalls

• Orphaned flags lingering in codebase.
• Too many flags evaluated at runtime — slows hot paths.
• No visibility into who toggled what or when.

📌 Final Insight

Feature flags are powerful but require discipline. Treat them like infrastructure — version, audit, monitor, and clean up as part of regular ops.