Your origin server is in Virginia. A user in Singapore: 180ms round-trip just to reach you, before any work. CDNs solved this for static content. Edge computing extends the same idea to code — run your business logic at one of 300+ PoPs near the user. Authenticate, rewrite, A/B test, personalize at the edge — never round-trip to the origin for these. Result: sub-50ms global latency, smaller origin load, lower egress bandwidth.
Cloudflare Workers, Vercel Edge, AWS Lambda@Edge, Fastly Compute. Different vendors, same idea: V8 isolates or WASM running globally.
02
What "edge" actually is
Three things conflated under "edge":
CDN edge — caches static assets at PoPs. The original "edge."
Edge functions — run small JavaScript / WASM functions at PoPs in response to HTTP requests. Sub-millisecond cold start.
Edge databases — replicated data stores accessible from edge functions (Cloudflare D1/KV/R2, Turso, Upstash). Read at the edge; writes still bottleneck through a region.
Combined: a request from Singapore hits a Singapore PoP, the edge function authenticates + reads from edge KV + responds — without ever touching Virginia. That's "the edge."
03
What runs well at the edge
Use case
Why edge wins
A/B test routing
Bucket users at the edge, no origin round-trip for the decision
Auth + JWT verify
Reject unauthenticated requests before they hit your origin
Geo / device routing
Edge knows the user's country + device — route to the right backend
Image transformation
Resize / WebP-convert on the fly at the edge; cached afterward
Bot detection / rate limiting
Block bad actors at the edge before they consume origin resources
HTML personalization
Inject user-specific elements into a cached HTML shell — "smart edge cache"
SEO redirects
Tens of thousands of legacy URL redirects served at edge instantly
04
What doesn't run at the edge
Heavy compute. Edge runtimes are CPU-limited (10-50ms typical, longer is throttled). Don't run ML inference on a ResNet at the edge.
Long-running processes. No background jobs, no WebSocket servers (with notable exceptions like Cloudflare Durable Objects).
Strict-consistency writes. Edge writes to a global datastore have to flow somewhere central — you don't escape physics.
Stateful services. Edge functions are stateless. Need state? Fetch from edge KV / database / origin.
Anything needing libraries. Edge runtimes are limited subsets of Node — no native modules, no filesystem, restricted Web APIs only.
05
Deep dive — the V8 isolate trick
Lambda cold-starts a container per function (50ms-500ms). Cloudflare Workers cold-starts a V8 isolate (under 5ms). The difference is what makes edge functions feasible.
A V8 isolate is a separate JavaScript heap inside the same V8 process. Creating one is microseconds, not milliseconds. Cloudflare runs hundreds of customer functions inside one V8 process, isolated by isolate boundaries. Memory + CPU per request is tiny because there's no container, no process, no JIT warm-up. Cost per request → essentially free.
Trade: you can't run arbitrary Node modules. You're inside V8 with the Service Workers Web Platform API surface. WASM works for non-JS code. WebAssembly modules also start in microseconds.
Lambda@Edge uses a different model: small Lambda runtime per request, slower cold starts (~100ms), but more compute headroom and Node.js compatibility. AWS Function URLs + Lambda are catching up; Cloudflare still leads on cold start.
Modern stack pattern
Auth, routing, A/B logic, SEO handling at Cloudflare Workers (free or near-free). Heavy app logic in regional functions or containers. Long-running APIs at origin. Each tier handles what it's good at.
06
Real-world
Cloudflare Workers
V8-isolate edge runtime
Sub-5ms cold starts, 300+ PoPs. KV + Durable Objects + D1 + R2 for state. Pricing rounds to ~$5/M requests.
Vercel Edge Functions
Edge runtime for Next.js
Built on Cloudflare under the hood. Tight Next.js integration; great DX for full-stack apps.
