Client-side vs server-side feature flags

WHAT THIS TESTS: Whether you can reason about where a feature flag is evaluated and the security, latency, and consistency consequences of that choice.

A GOOD ANSWER COVERS: Client-side flagging evaluates the flag in the user's browser or mobile app via an SDK. It is fast once loaded and can work offline, but the flag configuration, including names of unreleased features and targeting rules, ships to the client and is visible to anyone inspecting network traffic or the bundle. Values can also go stale between SDK refreshes, and a malicious user can flip a client flag locally. Server-side flagging evaluates on the backend, so logic and the very existence of hidden features stay secret, values are consistent and authoritative, but every decision may need a round trip and offline evaluation is not possible without local caching.

COMMON WRONG ANSWERS: Saying one approach is always better, ignoring that client flags leak unreleased work, or forgetting the latency cost of server evaluation.

LIKELY FOLLOW-UPS: How do you keep client flags from leaking? How do you ensure consistency across a request that touches both layers? How do you cache server flags safely? How do flags interact with edge or CDN rendering?

ONE CONCRETE EXAMPLE: For an unannounced premium pricing tier, prefer server-side evaluation: the gating decision and the existence of the feature must not be discoverable by inspecting the client, and the entitlement check is security-sensitive, so it belongs on the trusted backend. By contrast, a simple cosmetic change like a new button color is a fine client-side flag, since exposure does not matter and evaluating in the browser avoids a round trip and flickers. Choosing the wrong side, putting the pricing gate client-side, would leak the unreleased tier and let users bypass the gate by toggling the flag locally.