Edge Computing
Date: 2026-08-16
Running code at the CDN, close to the user, instead of at a single origin. It removes a round trip’s worth of distance — and imposes a constrained runtime with no database, which is why it suits decisions rather than work.
What it is
Edge computing executes application logic on CDN points of presence, geographically near the requester, rather than at a central origin server.
CONVENTIONAL EDGE
user (Manchester) user (Manchester)
│ ~200ms │ ~15ms
▼ ▼
origin (Virginia) edge (Manchester)
decides, renders decides
│ │ cache hit → done
▼ │ miss → origin
response ▼
response
What it’s good at
The runtime is constrained — short execution limits, limited memory, no persistent connections, no direct database access. So the work that suits it is decisions, not computation:
- Routing and redirects. Country or language routing without a round trip to origin — Redirects and Link Equity
- A/B assignment. Deciding a variant at the edge removes the client-side flicker problem entirely — Client-Side vs Server-Side Testing, Flicker and Flash of Original Content
- Authentication checks. Reject unauthenticated requests before they reach origin
- Header manipulation. Security headers, cache keys, feature flags
- Personalisation of a cached page. Assemble cached fragments with a small dynamic piece
- Bot filtering and rate limiting — Rate Limiting
In plain terms: the edge is a good place to decide what should happen and a poor place to do the heavy lifting. Anything needing your database is going to your origin regardless, so putting it at the edge adds a hop rather than removing one.
The caching interaction
The most important and most easily broken part. If edge code varies the response, the cache key must vary with it — or users receive each other’s versions.
edge decides variant A or B from a cookie
cache key = URL only
→ the first user to arrive caches their variant for everyone
Every edge platform provides a way to add to the cache key. Getting this wrong is how one customer’s personalised page ends up served to another — the worst failure mode available here. See CDN Caching.
The corollary: every dimension you add to the key multiplies stored objects. Country plus device plus variant is a lot of copies of the same page, and hit rate falls accordingly. Keep the varying dimensions few and coarse.
Where it doesn’t help
- Database-bound work. Your data lives somewhere; edge code either travels to it or you replicate, and replication is its own project
- Anything CPU-heavy. Execution limits are short by design
- Pages already cached well. If the CDN is serving a static hit, there’s no origin round trip to remove
- Sites with concentrated traffic. Serving mostly-UK traffic from a UK origin already has low latency; the edge’s benefit is proportional to how spread out your users are
That last one is worth stating plainly for a UK retailer: if nearly all your customers are in one country and your origin is in that country, edge rendering is solving a problem you don’t have. The wins are in caching and origin speed instead — Time to First Byte, CDN Caching.
The runtime constraint
Edge runtimes are not Node. They’re typically a restricted JavaScript environment based on web standards, which means:
- No filesystem, no native modules, no long-lived connections
- Many npm packages simply won’t run
- Cold starts exist, though they’re generally short
- Debugging is harder — you’re reproducing a constrained environment locally
Check that your dependencies work at the edge before designing around it. Discovering that your ORM or SDK can’t run there is a late and expensive finding.
Where it connects
- Rendering Strategies — edge rendering as one option among several
- CDN Caching — the cache key discipline that makes it safe
- Progressive Delivery — edge is a natural place to implement percentage rollouts
- Vercel · Cloudflare — the platforms, and their differing runtime constraints