Client Feature Flags

Definition

Feature flags evaluated on the client. Same concept as server-side flags, materially different constraints.

What makes them harder

Distribution lag. A flag changed on the server takes time to reach clients, which have cached values. "Instant rollback" is instant server-side and takes minutes client-side — that difference matters during an incident.

Deployed versions cannot be upgraded. Mobile clients from a year ago are still running. A flag must behave sensibly for every version in the field, forever, which means flags accumulate rather than being cleaned up on a deployment.

Offline behaviour. A client with no connection must have a cached value and a sensible default. A flag system that blocks rendering while fetching is a self-inflicted outage.

Exposure. Flag names and values are visible to anyone inspecting the client. Never use a client flag for anything security-relevant, and be aware that unreleased feature names leak.

Consistency with the server. If the same flag is evaluated in both places and they disagree — because the client's cache is stale — the user sees an incoherent experience. Either evaluate once on the server and pass the result, or design so disagreement is harmless.

The design that works

• Evaluate on the server where possible, and send the resolved values to the client. Removes distribution lag, disagreement and exposure at once.
• Bootstrap with the page or session, so no additional round trip is required.
• Cache locally with a safe default, and never block rendering on flag retrieval.
• Stable assignment, hashed on a persistent user identifier, so a user does not flip between variants across sessions or devices.
• Design for stale. Assume some clients have old values for a while and ensure both states are acceptable.

The mobile-specific point

Because old app versions persist, flags used for mobile rollout are effectively permanent surface area. Plan for a flag to be evaluated by a version released three years ago, and make the default behaviour for unknown flags explicit and safe.

Failure scenarios

• Rendering blocked on flag retrieval.
• No offline default, so the app is broken without connectivity.
• Server and client disagreeing, producing an incoherent interface.
• Security decisions in client flags.
• Assignment not stable, so users flip between variants and experiments are invalidated.

Interview question

"How do client-side feature flags differ from server-side ones, and what breaks if you ignore the difference?"