Edge resolvers evaluate feature flags at the CDN or edge compute layer, before a request reaches the origin server. Flag resolution happens at the network boundary, in the data center closest to the user, minimizing latency by cutting out both the round-trip to a central flag service and the trip to the origin.
For applications where the flag determines what the user sees on first load (a different landing page, a personalized hero banner, a redirected URL), evaluating the flag at the edge means the user never waits for the origin server to make the decision. The edge node computes the variant, serves the right response, and the origin might never need to be involved at all.
How do edge resolvers work?
Edge resolvers run flag evaluation logic in edge compute environments like Cloudflare Workers, AWS Lambda@Edge, Fastly Compute, or Vercel Edge Functions. The flag configuration is replicated to the edge network, and when a request arrives, the edge function evaluates the flag rules against the request context (user ID from a cookie, geographic location from the CDN, device type from the User-Agent header) and returns the appropriate variant.
The evaluation itself uses the same deterministic assignment logic as local evaluation: a hash of the user ID and salt maps the user to a bucket, the bucket determines the variant. The difference is where this computation runs. Local evaluation runs inside your application process. Edge evaluation runs on the CDN's distributed infrastructure, before your application code executes.
Confidence's edge evaluation mode supports this pattern. The flag configuration syncs to the edge layer, and the OpenFeature-compatible SDK runs the evaluation in the edge function. Like local evaluation, the result resolves without a network call to Confidence's cloud service.
When should you use edge resolvers?
Server-side rendering with personalization. If your web application renders pages on the server and the flag determines which page variant to render, edge evaluation avoids a round-trip to a central flag service before the server can even start rendering. The edge node resolves the flag and passes the result to the origin (or serves a cached variant directly).
Geographic targeting at the network layer. CDN edge nodes inherently know the user's approximate location. Evaluating location-based flags at the edge (show pricing in local currency, route to a regional backend, enable a feature for users in specific markets) is natural because the targeting attribute is already available.
Redirect and routing decisions. A/B tests that route users to entirely different URLs or backend services benefit from edge evaluation because the routing decision needs to happen before the request reaches any origin.
First-paint latency optimization. For client-side applications, the flag evaluation typically happens after the JavaScript bundle loads. Edge evaluation can embed the flag result in the initial HTML response, eliminating the flash of default content while the client-side SDK initializes.
How do edge resolvers compare to local and cloud evaluation?
Confidence offers three flag resolution methods: cloud, local, and edge.
Cloud evaluation sends each flag check to Confidence's cloud service and gets back the resolved variant. Simple to set up. Adds network latency. Creates an availability dependency.
Local evaluation caches the flag configuration in your application process. Evaluations run in microseconds. Works for server-side and mobile SDKs. No latency or availability penalty after the initial sync.
Edge evaluation runs the same in-process logic at the CDN layer. Best for decisions that need to happen before the request reaches your origin, or where you want to use the edge network's geographic distribution.
The three modes aren't mutually exclusive. A typical architecture might use edge evaluation for routing decisions and first-paint flags, local evaluation for server-side feature flags in backend services, and cloud evaluation for low-volume administrative tools where latency isn't critical.