Flag evaluation

There are two models. In local evaluation, the SDK holds the flag configuration in memory and computes the result itself — a sub-millisecond lookup with no per-check network call — and receives configuration updates over a streaming connection. In remote evaluation, the SDK asks a server for each result, adding network latency to every check. Featureflip's server-side SDKs evaluate locally; the reliability guide covers how they fail safe when the service is unreachable. The model also shapes cost: vendors that bill per client-side MAU or per flag request meter evaluation volume itself, which is why teams whose traffic outgrew that bill weigh the LaunchDarkly alternatives that price evaluation differently.

Evaluation runs against the user context you pass — identifier, attributes, and group membership — checking segment targeting and rules in order. The order matters: a failed prerequisite short-circuits the rest, and the first matching rule wins. Each result carries a reason — rule match, fallthrough, prerequisite failed — so you can see exactly why a user got the variation they did. This same deterministic machinery is what makes A/B testing and gradual rollouts repeatable.