A team wants to run personalized A/B test bucketing logic on every request at the CDN edge (for example, using Cloudflare Workers or a similar edge-compute platform) instead of in their origin application server. What kinds of logic are a good fit for that edge-compute layer, and what would make you push back and say 'this belongs in the origin, not the edge'?

## What edge compute is Edge compute platforms — **Cloudflare Workers**, **Fastly Compute**, and **Lambda@Edge/CloudFront Functions** are the well-known examples — let a developer deploy a small function that runs on the CDN's own PoPs, intercepting a request before it would otherwise be handled purely as a cache lookup or forwarded to origin. Mechanically, these are typically short-lived, sandboxed execution environments: Cloudflare Workers, for instance, run inside **V8 isolates** (the same lightweight JavaScript execution sandbox that powers a browser tab, minus the browser around it), which start far faster than a full container or VM but are correspondingly constrained in what they can do. A request hits a PoP, the edge function runs synchronously as part of handling it — reading headers, cookies, or the URL, and deciding to rewrite the request, answer immediately from logic alone, or forward it onward to a cache lookup or the origin — and the response continues on its way. ## Why this layer exists The reason this layer exists is to push cheap, per-request decisions as physically close to the user as possible, shaving away round trips that would otherwise require a full trip to origin just to make a small decision. Two things converge to make this valuable: 1. **The latency argument** from CDN PoP placement generally — deciding something in Tokyo instead of Virginia saves the same round trip that caching a static file does. 2. **An economic argument** — offloading simple, high-volume logic (like assigning an A/B test bucket on every single page view) from the origin fleet to the CDN's compute layer can meaningfully reduce origin server count and cost at scale, since the edge absorbs work that would otherwise all funnel back to one place. ## The trade-off The trade-off is that edge runtimes are deliberately, not incidentally, constrained. - **Execution time and memory are capped**, often quite tightly, to keep the sandbox lightweight and fast to start; there's usually no arbitrary native dependency support, ruling out heavyweight libraries or long-running computation. - **State is the sharper constraint.** An edge function instance is ephemeral and tied to one PoP, with no reliable local persistent storage — anything that needs to be read or written durably has to go through a separate edge key-value store (itself typically eventually consistent across PoPs, replicating asynchronously) or back to origin, both of which reintroduce some of the latency the edge was supposed to avoid. - **The billing model shifts too**, from provisioning server-hours to paying per invocation or per unit of CPU time, which is cheap for lightweight logic run at massive scale but can become expensive quickly if the logic is heavier than it should be. ## Failure modes Failure modes cluster around exactly these constraints being violated or underestimated. - **Cold starts** — the cost of initializing a fresh isolate the first time (or after eviction) a function runs at a given PoP — can spike tail latency noticeably for lower-traffic routes or less-visited PoPs, unlike an always-warm origin server pool. - **Treating an edge KV store as if it offered strong, immediate cross-region consistency** is a classic mistake: a value written in one region may not yet be visible to a function running in another PoP, which is fine for something like A/B bucketing (a few seconds of eventual staleness is harmless) but genuinely dangerous for something like a real-time inventory decrement or an account-suspension check, where a stale read can cause overselling or a security gap. - **Deployment risk is structurally different** from origin deployments: edge function updates typically roll out to every PoP globally at once, with no built-in per-region canary the way a fleet of origin servers can be updated region by region, so a bug in an edge function can affect essentially all global traffic almost immediately unless the team has built its own staged rollout tooling on top of the platform. - **A practical vendor lock-in cost:** edge runtimes expose proprietary APIs (their own KV store, their own request/response object shapes) that don't port cleanly between providers. ## The heuristic In practice, the right heuristic is: - **Keep at the edge** whatever is cheap, mostly stateless, and tolerant of eventual consistency — A/B bucketing from a deterministic hash of a stable cookie value, security header injection, simple auth-token format validation, geo-redirects, or lightweight response personalization. - **Keep at origin** anything that needs strong consistency, meaningful compute, or coordination across multiple backend systems, such as checkout and payment logic, or any decision that must never be stale even for a few seconds.