Client-side vs server-side feature flags
Flag evaluation placement.
client-side is fast and offline-capable but exposes flag logic and risks stale or leaked values; server-side keeps logic secret and consistent but adds latency.
What's really being asked
Whether you can reason about where a feature flag is evaluated and the security, latency, and consistency consequences of that choice.
The full answer
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.
The mistakes people make
Saying one approach is always better, ignoring that client flags leak unreleased work, or forgetting the latency cost of server evaluation.
What usually comes next
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?
A 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.
Interview question
For gating an unannounced premium pricing tier, why is server-side feature flag evaluation strongly preferred?
- a.Client-side flags cannot support percentage rollouts
- b.Server-side flags never require a network round trip
- c.It keeps the feature's existence and entitlement logic off the untrusted clientCorrect
- d.Client-side evaluation is always slower than server-side
Why? this is the answer
Server-side evaluation hides unreleased features and keeps security-sensitive entitlement checks on the trusted backend, where users cannot flip them. Client-side flags ship config to the browser, leaking the tier and letting users bypass the gate locally.
Just read this? Test yourself on what you have been reading.
Read the original → posthog.com
- #feature-flags
- #client-vs-server
- #security
- #release-management
- #trade-offs
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles