When a feature flag has multiple targeting rules, for example always off for free-tier users, always on for internal staff, and a 50% rollout for everyone else, how does a flag evaluation engine typically resolve conflicts between rules, and what architectural trade-offs come from evaluating those rules client-side in a browser or mobile SDK versus server-side?

## Targeting rules are a small ordered rules engine A targeting rule set turns a flag from a single on/off switch into a small rules engine: each rule pairs a condition with an outcome -- serve variant A, or fall through to the next rule. A condition can be: - An attribute match, such as plan equals enterprise. - A segment membership check, such as user is in the internal-staff segment. - Or a combination. Nearly every production flag platform evaluates these as an ordered list: the engine walks the rules top to bottom for a given user's attributes and returns the outcome of the first rule that matches, falling through to a final catch-all clause, typically the percentage rollout, if no explicit rule matches. This means **rule order is semantically load-bearing**: a "free-tier users always off" rule placed before an "internal staff always on" rule would incorrectly deny an internal staffer who happens to also be tagged free-tier, whereas placing the staff-override first correctly lets it win. Reordering two rules that look independent can silently change behavior for any user who matches more than one, which is why flag platforms treat rule reordering as an auditable change, not a cosmetic edit, and why "which rule wins when several match" is one of the first questions worth asking about any targeting rule set you inspect. ## Why targeting exists at all The reason targeting exists at all, layered on top of a simple percentage rollout, is that real releases rarely want a single uniform slice of users -- they want specific, named cohorts such as: - Internal staff for dogfooding. - A beta customer list. - A geographic region for a compliance-gated launch. - A paid tier for entitlement. Those are combined with a general randomized rollout for everyone else. Building this as a general rule engine rather than one-off code branches means product or support staff can add or adjust cohorts through a dashboard without an engineer writing new conditional code for every new segment. ## Client-side versus server-side evaluation The client-side versus server-side evaluation question is a genuinely consequential architecture decision, not just an implementation detail. | Client-side evaluation | Server-side evaluation | |---|---| | The SDK computes the match locally, in the browser or mobile app | The backend keeps the rule set and the evaluation itself | | Lowest possible latency; keeps working offline using last-known rules | Adds a hop of latency unless cached well; depends on a live, or locally cached-with-sync, service reachable from the server process | | Cost is exposure of rules and flag keys | Keeps rules private; evaluation can use server-only signals | In **client-side evaluation**, the SDK running in the browser or mobile app receives the full rule set for the flags it's configured to know about, along with the current user's attributes, and computes the match locally. This gives the lowest possible latency, since no network round trip is needed at evaluation time, and lets the app keep working using last-known rules even offline. The cost is exposure: a client-side SDK payload, or the rules embedded in a mobile app's local cache, can be inspected by anyone with browser devtools or a decompiled app package, which reveals not just the existence of a flag but its exact targeting logic -- a rule like `if company_domain contains competitor.com then off` is now public knowledge, and worse, the mere presence of a descriptively named flag key in client-shipped config can leak an unreleased feature's existence before launch, an information-disclosure risk that matters a lot for embargoed announcements or entitlement logic a competitor could reverse-engineer. **Server-side evaluation** instead keeps the rule set and the evaluation itself inside the backend, returning only the resolved outcome to the client, or not even that, since the server just behaves differently. This keeps rules private and, just as importantly, lets evaluation use server-only signals that should never ship to a client at all, such as real-time fraud or risk scores, internal account metadata, or billing state pulled fresh from a database, none of which belong in a browser payload. The cost is architectural: every evaluation now depends on a live, or locally cached-with-sync, service reachable from the server process, adds a hop of latency if not cached well, and can't trivially support fully offline client behavior the way an embedded client SDK ruleset can. ## The hybrid platforms converge on In practice, most serious flag platforms support a hybrid: server-side evaluation for anything sensitive, such as unreleased features, entitlement or permission logic, or fraud-adjacent behavior, and client-side evaluation, often via a lightweight already-resolved payload rather than the raw rule set, for latency-sensitive or purely cosmetic UI flags where leaking the logic carries no real cost. A well-known concrete pattern is LaunchDarkly's distinction between server-side SDKs, which can see the full rule set and private context, and client-side SDKs, which by default only receive a pre-filtered set of flags marked available to client-side contexts, specifically to avoid shipping unreleased-feature names or sensitive targeting logic into a browser bundle -- an explicit acknowledgment in the tooling itself that this is a real security and product boundary, not just a performance knob. ## The failure mode in the wild The failure mode this produces in the wild is a predictable one: a team building a mobile-first product defaults every flag to client-side evaluation for simplicity and speed, and months later an unreleased pricing change or an internal-only admin feature's flag key and targeting rules turn up in a decompiled app package or a public bug-bounty report, because nobody drew the line between safe-to-leak and must-stay-server-side at the point each flag was created.