Server-Side vs Client-Side Evaluation: How Feature Flag Vendors Differ

Every feature flag platform makes a fundamental architecture choice: where does flag evaluation happen? Some vendors download targeting rules to your SDK and evaluate locally. Others keep rules on the server and return pre-computed results. This decision shapes everything downstream: privacy, latency, SDK complexity, and how real-time updates work.

Here’s how the major vendors differ, and why it matters for your stack.

The two models

Client-side evaluation

In this model, your SDK downloads the full set of targeting rules from the flag service. When your code calls getBooleanValue('my-flag', false), the SDK evaluates the rules locally against the user context you provide. No network call happens at evaluation time.

┌───────────────────┐            ┌───────────────────┐
│    Your SDK       │◀───rules───│  Flag Service     │
├───────────────────┤            ├───────────────────┤
│  evaluate(        │            │  (rule storage)   │
│    rules,         │            │                   │
│    userContext    │            │                   │
│  ) → result       │            │                   │
└───────────────────┘            └───────────────────┘

The SDK is “fat”, it contains a full evaluation engine capable of matching targeting rules, evaluating segments, and computing percentage rollouts.

Server-side evaluation

In this model, your SDK sends the evaluation context (user ID, attributes) to the flag service, which evaluates the rules and returns the result. The SDK is a thin HTTP client.

┌───────────────────┐            ┌───────────────────┐
│    Your SDK       │──context──▶│  Flag Service     │
├───────────────────┤            ├───────────────────┤
│  (HTTP client)    │◀──result───│  evaluate(        │
│                   │            │    rules,         │
│                   │            │    context        │
│                   │            │  ) → result       │
└───────────────────┘            └───────────────────┘

The SDK doesn’t know anything about your targeting rules. It sends context, gets back a value.

Who does what

The answer isn’t always straightforward. Most vendors use different models depending on where the SDK runs.

LaunchDarkly uses a hybrid approach. Browser SDKs receive pre-evaluated flag values from the server via a streaming connection, so the SDK never sees the rules. But backend SDKs download the full rule set and evaluate locally, making them fat SDKs with a complete evaluation engine.

ConfigCat is pure client-side evaluation everywhere. Every SDK (browser, server, mobile) downloads a config.json containing all rules and evaluates locally. The flag service is essentially a CDN-backed config file.

Flagsmith defaults to server-side evaluation (remote API calls). Backend SDKs can optionally switch to local evaluation by polling an “environment document” with full rules, but the default mode is remote.

Unleash runs client-side evaluation on backend SDKs, which download all feature toggles and evaluate locally. For frontend clients, Unleash routes requests through a proxy layer that evaluates flags server-side and returns results.

Flipswitch uses server-side evaluation everywhere via OFREP (OpenFeature Remote Evaluation Protocol). Both browser and backend SDKs send context to the server, which evaluates rules and returns results. SDKs are thin HTTP clients with SSE connections for real-time updates.

All of these vendors deploy edge infrastructure (CDN nodes, edge proxies, edge workers) to reduce latency between SDKs and the flag service. This is standard across the industry. The evaluation model determines what runs at the edge, not whether there’s an edge layer at all.

Privacy: two different concerns

When people talk about “privacy” in feature flags, they usually conflate two separate things:

1. Privacy of business logic: Can someone inspect the network traffic or SDK state and see your targeting rules? Percentage splits, internal user segments, canary rollout strategies, these are business decisions you may not want exposed.

2. Privacy of user data: Does user context (email, plan, attributes) get sent to the flag vendor’s infrastructure?

These are different concerns, and no vendor gets both for free.

Rules visible in the browser?

Client-side evaluation requires shipping your targeting rules to the SDK. If that SDK runs in a browser, anyone with DevTools can inspect the full rule set. They can see which segments exist, what the rollout percentages are, and what attributes you’re targeting on.

Server-side evaluation avoids this entirely. The browser only sees evaluated results, never the rules behind them.

User data sent to the vendor?

Server-side evaluation means sending the evaluation context to the flag service. For hosted services, that means user attributes leave your infrastructure and travel to the vendor. For self-hosted platforms, this is less of a concern since you control the server.

Client-side evaluation keeps user data local. The SDK evaluates rules on-device, and no user context needs to leave the client.

The evaluation proxy: best of both worlds

The table above assumes you use the vendor’s hosted service directly. But every major vendor offers a self-hosted proxy component that runs in your infrastructure, syncs flag configurations from the cloud, and evaluates flags locally. User context never leaves your network, because evaluation happens on a server you control.

This gives you the privacy benefits of both models: rules stay hidden from the browser (server-side evaluation) and user data stays in your infrastructure (local evaluation). The trade-off is operational: you’re now running and maintaining another service. For teams already comfortable with that, it largely eliminates the privacy row from the comparison.

Real-time updates

Regardless of where evaluation happens, every vendor needs a way to propagate flag changes from the dashboard to running applications. The models differ in what gets pushed and how fast it arrives.

ConfigCat uses polling only. SDKs check for a new config.json on a configurable interval, defaulting to 60 seconds. There’s no push mechanism, so if you change a flag, SDKs won’t know until the next poll. This is a deliberate trade-off for simplicity and CDN-friendliness.

LaunchDarkly uses SSE streaming. Browser SDKs receive pre-evaluated values in real-time. Backend SDKs receive updated rules over the same stream. Changes propagate in milliseconds.

Flagsmith offers SSE streaming on enterprise plans. The stream sends a lightweight timestamp notification (“something changed”), and the SDK must re-fetch the full config to find out what. Free/startup plans rely on polling.

Unleash uses polling. SDKs periodically fetch the latest config and receive updates on their next poll interval.

Flipswitch uses SSE to push change notifications to all connected SDKs. When a flag changes, the SDK receives a notification with the flag key and re-evaluates via OFREP. Changes propagate in real-time on all plans.

The key insight: real-time update capability is orthogonal to the evaluation model. You can have client-side evaluation with real-time push (LaunchDarkly server SDKs) or server-side evaluation with polling (Flagsmith free tier). The evaluation model determines what gets sent, not whether you can send it fast.

SDK complexity and the multi-language problem

Here’s where the evaluation model has the most practical impact on platform maintainability.

Client-side evaluation means N evaluation engines

If your SDK evaluates flags locally, it needs a full evaluation engine: rule matching, segment evaluation, percentage hashing, semantic version comparison, and whatever other operators your targeting language supports.

That engine must be implemented correctly in every language you support. LaunchDarkly maintains evaluation engines in roughly 10 server-side languages. ConfigCat maintains them across 15+. Every new operator or targeting feature must be ported to all of them, and a subtle bug in one language’s percentage hashing means different users get different results depending on whether the flag was evaluated in Go or Python. These bugs are real, hard to catch, and hard to debug in production.

Unleash is tackling this by using a single evaluation engine written in Rust that gets embedded into each SDK via language-specific bindings. This reduces the consistency problem significantly, though it trades one kind of complexity for another: native bindings and FFI in every SDK.

Server-side evaluation: the simplest SDKs

With server-side evaluation, SDKs don’t evaluate anything. They’re HTTP clients that send context and receive results, plus an SSE listener for real-time updates. That’s it.

Adding a new language SDK means writing an HTTP client and an SSE parser, both well-solved problems in every language. There’s no evaluation engine to port, no consistency tests to maintain across languages, no edge cases in rule matching to discover six months after launch.

This is one of the main reasons Flipswitch uses server-side evaluation via OFREP. The evaluation engine exists in exactly one place (the server), and SDKs are thin, predictable, and easy to build.

Vendor comparison at a glance

Which model is right for you?

Neither model is universally better. The right choice depends on what you’re optimizing for.

Choose client-side evaluation if:

• You’re comfortable exposing rules. If your targeting rules aren’t competitively sensitive, the trade-off is acceptable.
• You want user data to stay on-device. In privacy-sensitive contexts where user data can’t leave the client, local evaluation avoids sending context to a vendor. That said, a self-hosted evaluation proxy achieves the same thing with server-side evaluation.

Choose server-side evaluation if:

• Targeting rules are sensitive. Rollout strategies, internal segments, and pricing experiments stay on the server.
• You want simpler SDKs. Less code in the SDK means fewer bugs, smaller bundle sizes, and less surface area to maintain.
• You want instant updates. When rules change on the server, the next evaluation reflects it immediately, no need to push new configs to every connected SDK first.

Wrapping up

The evaluation model is one of those foundational choices that ripples through every part of a feature flag platform. It determines what your SDKs look like, what’s exposed in the browser, how fast changes propagate, and how much engineering effort goes into cross-language consistency.

Flipswitch chose server-side evaluation via OFREP because we value thin SDKs, keeping targeting rules on the server, and building on open standards. It’s the right trade-off for us, but now you have the full picture to decide what’s right for you.

Try Flipswitch for free, set up your first flag in about 5 minutes, no credit card required.