Which workloads genuinely belong at the edge, and which become harder there because of state, consistency, debugging or resource limits?

What belongs at the edge

The common property is request-scoped work with no shared mutable state:

• Routing and rewriting. Deciding which origin or which cached variant serves a request.
• Authentication and authorisation checks against a token that can be validated without a lookup — rejecting unauthorised requests at the edge saves an entire round trip to origin and protects it.
• Personalisation on top of cached content. Serve one cached page and inject the user-specific fragment at the edge, which turns an uncacheable personalised page into a cacheable one plus a small transformation. This is the highest-value edge pattern in most content systems.
• A/B assignment, deterministic from a cookie or identifier.
• Rate limiting and bot mitigation, which must happen before traffic reaches origin to be useful.
• Image and content negotiation — format, resolution and compression chosen per device.

What becomes harder

Anything owning mutable shared state. Edge locations number in the hundreds; coordinating writes across them is a globally distributed consensus problem. The moment an edge function needs to read and write shared data consistently, the latency benefit evaporates because it must reach the authoritative store anyway — and you have added a hop.

Large or long computations. Edge runtimes have tight CPU and memory limits and short execution budgets. Work exceeding them belongs in a region.

Anything needing a database connection. Connection-oriented protocols do not suit a runtime that starts and stops per request, and hundreds of locations each holding connections exhausts the database's limits.

Debugging and observability. A bug reproducible only in one of hundreds of locations, under one network condition, is genuinely hard to investigate. Distributed tracing and structured logging must be in place from the beginning rather than retrofitted.

Deployment and configuration consistency. Propagating a change to hundreds of locations introduces a window where behaviour differs by location — which is the source of the most confusing edge bugs.

The framing that resolves it

Move the decision to the edge; keep the truth in the centre. Edge code decides what to serve, whether to allow, which variant, which origin — using data it can validate or cache. It does not become the system of record for anything.

When edge state is genuinely required, it needs an explicitly scoped consistency model: a coordination primitive with a single authoritative location per key, rather than an assumption that state is globally available.

The trade to state honestly

Edge execution buys latency and origin protection, and costs debuggability, deployment complexity and a constrained runtime. For a request-scoped transformation the trade is excellent. For anything with state, the honest question is whether the latency saved exceeds the complexity added — and the answer is usually no unless the state is read-mostly and can tolerate staleness.