Rolling out storefront changes at the edge: feature flags without the origin round trip
Every storefront change carries the same risk: the new version might be worse than the old one. Feature flags at the edge let you roll changes out to a fraction of traffic, measure the effect, and roll back instantly, all without redeploying your origin or waiting on cache purges.
What an edge feature flag actually is
A feature flag is a conditional in your request path: if the shopper is in the test group, serve the new experience; otherwise, serve the current one. Running that conditional at the edge means the decision happens at the POP closest to the shopper, before the request ever reaches your origin. The origin serves both variants; the edge decides which one each shopper sees.
This is different from client-side flags, where JavaScript decides which variant to render after the page loads. Client-side flags are simple to implement but they create flicker: the shopper sees one version, then the page swaps to another. They also slow down the page, because the flag evaluation and the variant logic compete with everything else the browser is doing. Edge flags resolve before any HTML is served, so the shopper gets exactly one version, rendered correctly the first time.
Why the edge is the right place for the decision
The edge already knows the facts that flag rules need: the shopper's geography, device class, whether they are cookied, and which experiment cohort they were assigned to. Evaluating the flag at the edge keeps all of that local. The alternative is doing it at the origin, which means the origin must stay in the critical path for every request, or doing it in the browser, which means exposing your flag rules and experiment assignments in client code.
There is also a caching argument. A common objection to edge flags is that they multiply cache variants: two versions of every page doubles your cache footprint. In practice this is manageable if you flag at the right granularity. Flag the component, not the page. A new checkout button variant only changes the checkout page, not the whole site. And most flags are temporary: they exist for the duration of the experiment, then the winner becomes the default and the flag disappears. The cache impact of a few short-lived flags is small compared to the cost of shipping a losing change to everyone.
How to assign shoppers to variants
Assignment needs to be sticky and deterministic. A shopper who sees variant A on Monday and variant B on Tuesday will contaminate your results and notice the inconsistency. The standard approach is to hash a stable identifier (a cookie value or a session token) together with the experiment name, and use the hash to assign a cohort. The edge does this in a few milliseconds, sets a cookie marking the cohort, and every subsequent request for that shopper resolves to the same variant.
Keep the assignment logic in one place. When flags are evaluated in five different layers (CDN config, edge workers, origin code, tag manager, client scripts), nobody can answer the question "which shoppers saw which version" with confidence. One flag evaluation point at the edge, with a log of every assignment, is what makes the experiment data trustworthy.
Measuring without the origin round trip
The point of a flag is the measurement, and edge flags pair naturally with edge analytics. The same layer that assigns the cohort can log the exposure event: this shopper, this experiment, this variant, this timestamp. Join that exposure log with your conversion events and you have experiment results without instrumenting your origin or waiting on a separate analytics pipeline to catch up.
Watch out for the classic trap: measuring too early. Edge flags make it tempting to check results after a few hours because the data is right there. Resist. Decide your sample size and run duration before the experiment starts, based on your baseline conversion rate and the minimum effect you care about. A flag that you flip based on a Tuesday afternoon reading is not an experiment; it is a coin toss with extra steps.
Rollout patterns that work
Start with internal traffic: your own team, then a small percentage of real shoppers, then a ramp. The edge makes ramps cheap because changing the percentage is a config change, not a deploy. If the new variant breaks something, the rollback is the same config change in reverse, and it propagates to every POP in seconds. Compare that to rolling back an origin deploy, which involves build pipelines, deploy queues, and the hope that the rollback itself does not break.
Also use flags for kill switches, not just experiments. A new payment method, a third-party script, a redesigned product page: each of these can sit behind a flag that defaults to the safe version. When something goes wrong at 2 AM, the person on call flips a flag instead of waking up the deploy pipeline. That difference is measured in minutes of downtime versus hours.
What flags cannot fix
Feature flags do not fix a slow origin or a bad cache strategy; they sit on top of your architecture, not underneath it. They also add operational complexity: stale flags accumulate, experiment names collide, and nobody remembers to clean up the flag from six months ago. Treat flags like branches in version control: name them clearly, give each one an owner and an expiry, and delete the ones that are no longer deciding anything.
Done right, edge feature flags turn releases from events into non-events. Small changes go out to small audiences, the data decides what sticks, and the origin never has to be the place where risky decisions get made. That is the whole promise of the edge applied to your release process: decide close to the shopper, measure honestly, and keep the blast radius small.
Frequently asked questions
What is a feature flag at the edge?
It is a switch evaluated where the request lands, on the edge network, that decides which version of a page or component a visitor sees. Because the decision happens before the request travels to the origin, the shopper gets the variant with no extra round trip and no flicker.
Why do flags at the origin cause flicker?
Origin evaluated flags often resolve after the page shell has already been sent, so visitors briefly see the default version before the variant swaps in. Edge evaluation decides before anything is sent, which removes the swap and the layout shift that comes with it.
Can edge flags run real A/B tests?
Yes, with consistent bucketing. The edge assigns each visitor a stable variant from a cookie or a hash of an identifier, so the same shopper sees the same version on every visit. Without stable assignment the test data mixes variants and means nothing.
What should never be behind an edge flag?
Anything involving payment authorization or account security state. Flags are a rollout and presentation tool. The moment money or credentials are involved, the decision belongs on systems built and audited for it, not in a traffic routing rule.