A platform can render at the edge, close to the user. Which workloads benefit, and which become harder?

Which workloads benefit

• Personalisation of otherwise cacheable content. The shared page is cached; the edge applies the per-user variation. This preserves the cache hit rate while delivering personalisation, which is the strongest case.
• Routing and rewriting decisions: geography-based redirects, experiment assignment, feature-flag evaluation, authentication checks that can be done from a signed token.
• Anything latency-sensitive whose inputs are local or cached, where the round trip to origin dominates.

Which become harder

• Anything needing a database. The edge is close to the user and far from the data, so a request that queries an origin database has added a hop rather than removed one — and this is the case teams most often get wrong.
• Anything with substantial computation, since edge runtimes are constrained in memory, CPU time and available libraries.
• Anything requiring consistency, since the edge is by definition distributed and coordinating between locations is exactly what it is not good at.
• Debugging, which is meaningfully harder across many locations with limited observability.
• Deployment and rollout, since a change reaching every location in seconds means anything that can push a fix everywhere can push an outage everywhere — requiring staged rollout by region with automated halt.

The decision rule

Move to the edge what depends only on the request and on cached or replicated data. Keep at the origin anything that depends on shared mutable state.

That rule resolves most cases, and the cases it does not resolve are usually attempts to move state to the edge — which is where the genuine difficulty lives and where the cost is consistency rather than latency.

The configuration hazard specific to edge

A revocation must propagate faster than the cache it is revoking. Ordinary configuration can be cached indefinitely with a fail-to-last-known-good posture; security-critical revocation needs a separate short-TTL, fail-closed channel — kept small so frequent fetching is affordable and a fail-closed posture is safe.

Using one channel for both means either revocation is slow or a control-plane outage becomes a customer outage.