Unlocking Cloudflare Workers: a practical guide to the edge

"The edge" sounds like marketing. In practice, Cloudflare Workers is a V8 isolate that runs inside a data center near your user, with milliseconds of cold-start and a tight budget on CPU time. Once you internalize those two facts, everything else about the platform falls out.

What you actually get

• Global low-latency — your code runs in whichever PoP terminated the TLS connection.
• No cold starts that matter — isolates are cheap; containers aren't the right mental model.
• Tight limits — 50ms CPU for the free tier, 30s wall for paid. This shapes what you build.
• KV, D1, R2, Queues — primitives for state. KV is eventually-consistent; D1 is SQLite; R2 is S3-shaped; Queues are at-least-once.

Where I've used it in production

I moved the pre-auth request handling for a small dashboard to Workers. Three things improved:

1. The p95 latency dropped — unsurprisingly, because the TLS termination and the response now happen in the same PoP.
2. The origin stopped paying for bot traffic. A Worker can reject the obvious cases cheaply.
3. A/B flag evaluation moved there too, so the origin no longer needed to know about experiments at all.

Where it leaks

• Long-lived connections: streams and SSE work, but you'll babysit them differently than on Node.
• Node APIs: not everything polyfills. Check compatibility flags before you commit.
• Debugging: wrangler tail is fine, but you'll miss real stack traces the first few times.

When not to use it

If your request takes 500ms of CPU and has to, don't force it into the edge. The edge is for things that can be fast and need to be global. Most backends don't need to be global.

---

My rule of thumb: move to the edge the code that would otherwise hit the origin before your auth layer. Anything past auth is usually fine where it was.