A streaming platform delivers feature flags to clients. What happens when the flag service is slow or unreachable?

The failure that must not happen

The application blocks on flag evaluation and the page does not render. A flag service is a configuration dependency, and configuration must never be able to prevent the product from loading. Yet this is the most common way client flag systems fail in production, because the naive implementation awaits the flag response before rendering.

What the design must include

• Defaults compiled into the client, so it can render correctly with no flag data at all. Every flag needs a safe default chosen deliberately — usually the current production behaviour.
• Cached flag values persisted locally, used immediately at startup while fresh values load in the background. This makes the common case fast and the failure case invisible.
• A short timeout with a fallback, never an unbounded wait.
• Flags delivered with the initial page payload where possible, removing the extra round-trip entirely and eliminating the flash of default content that a separate fetch causes.
• Evaluation done server-side or at the edge for anything affecting the first render, since a client-side decision necessarily happens after the default has already painted.

The subtler problems

Flag changes mid-session. A flag flipping while a user is in a flow can produce an inconsistent experience — half the flow in one variant. Pinning flag values for the session duration avoids it, at the cost of slower propagation for genuine kill switches, which therefore need to be exempt.

Flags multiply the state space. Twenty independent flags produce more combinations than can be tested, and the combination a given user experiences may never have been exercised. This argues for few long-lived flags and aggressive removal of finished ones — flag debt is real technical debt and it compounds.