How do I prevent flags from leaking into performance-critical paths?

Evaluate flags once per request (or per session) and cache the result in context. Avoid flag checks inside tight loops. For JVM/Node, use provider-side streaming for near-zero latency and fall back to last-known values on provider timeouts.

Should flags live in the same repo as code?

Treat flags as configuration with their own lifecycle. In practice: a dedicated flags repo synced via ArgoCD to your providers, referenced from service repos via submodules or automation. Critical part is PR-based review, policy checks, and audit trails.

When do I delete a flag?

Set TTLs on creation. Once exposure is 100% and the feature is stable for N days (7–14 is common), open an automated PR to remove the dead code and the flag definition. Aging flags increase cognitive load and risk.

Do I still need canary deploys if I have flags?

Yes. Flags protect feature-level behavior. Canaries protect infrastructure and dependency changes. Use both: canary the binary, flag the behavior.

What if a vendor (e.g., LaunchDarkly) is down?

Use OpenFeature with streaming + local evaluation. Providers like `flagd` or LD SDK cache flag values and default to last-known-good on outages. Always design a safe OFF default and idempotent fallbacks.

Release-engineering · Nov 2, 2025 · 9 minute read

The Feature Flag Playbook That Halved Our Change Failure Rate

Flags aren’t magic. Done right, they turn scary releases into small, reversible bets. Here’s the design and the checklists that actually scale.

Back to all posts

The Feature Flag Playbook That Halved Our Change Failure Rate

Key takeaways

Implementation checklist