Edge computing patterns for web apps

Edge computing is not a silver bullet. Some patterns thrive at the edge; others fail badly. This is a field guide to both.

What the edge is good at

1. Caching and revalidation

The edge is closer to your users. Caching at the edge is the single highest-leverage performance win available to most web apps.

Pattern: stale-while-revalidate with tag-based invalidation. Serve stale content immediately, revalidate in the background, and invalidate by content tag (not URL) when the underlying data changes.

2. A/B testing and personalization

Edge workers can branch on cookies, headers, or geography without touching your origin. This makes A/B testing and lightweight personalization trivial.

Pattern: edge-side branching. Read a cookie in the edge worker, render the right variant, and never wake up your origin.

3. Authentication and session checks

Session validation at the edge means unauthenticated requests never reach your origin. This is a security win and a performance win.

Pattern: edge-side auth gate. Validate the session cookie in the edge worker. Reject invalid sessions before they hit the origin.

4. Redirects and rewrites

Legacy URL redirects, geo-based rewrites, and feature-flag routing are all natural fits for the edge.

Pattern: edge routing table. Keep a routing config at the edge. Update it without redeploying your origin.

What the edge is bad at

1. Long-running compute

Edge workers have strict CPU and wall-clock limits (often 30s wall, 50ms CPU). Anything that does heavy compute — image processing, video transcoding, large ML inference — does not belong at the edge.

Anti-pattern: image processing at the edge. Use a dedicated service or your origin. The edge is not built for it.

2. Stateful operations

The edge is stateless by design. Sessions, databases, and queues live at your origin or in a managed service. The edge can read from them, but it should not own them.

Anti-pattern: edge-side database. It will work in dev and break in prod. Use a managed edge KV store for ephemeral state, and your origin database for everything else.

3. Complex business logic

If your edge worker is more than 200 lines of code, you are probably doing too much at the edge. Edge workers should be small, fast, and obvious. Complex logic belongs at the origin, where you can debug it.

Anti-pattern: edge-side business rules. Use the edge for routing and caching. Push business logic to the origin.

4. Strong consistency

The edge is eventually consistent. Different POPs may serve different versions of your data for a few seconds. If you need strong consistency (a banking app, a checkout flow), do that at the origin.

Anti-pattern: edge-side checkout. The edge will lose a sale eventually. Do checkouts at the origin.

A pattern I keep coming back to

Edge for read, origin for write.

Reads go to the edge: cached, fast, close to the user. Writes go to the origin: consistent, transactional, auditable. The edge invalidates its cache when the origin signals a change.

This pattern handles 90% of web app workloads. It is boring. It works.

Closing

The edge is a tool, not a religion. Use it where it helps; do not use it where it hurts. The teams that get the most out of the edge are the ones that treat it as one option among many — not as the answer to every question.