intermediate 2 min answer

A team wants to move logic to edge functions. What are the genuine constraints, and which logic should stay at the origin?

verceledgeconstraintsstatelatency
Show the full answer Hide the answer

The genuine constraints

  • Limited runtime. Restricted memory, restricted CPU time, and a subset of the platform APIs — so libraries that assume a full runtime do not work, and discovering that late is common.
  • Distance from data. The edge is close to the user and far from the database — so a function that queries an origin store has added a hop rather than removed one, which is the mistake teams most often make.
  • No shared state, since each location is independent and coordinating between them is exactly what the edge is not good at.
  • Cold starts, smaller than a container's and not zero, which matters for a rarely-hit location.
  • Debugging across many locations with limited observability.

What belongs at the edge

Anything depending only on the request and on cached or replicated data: routing, rewriting, geography decisions, experiment assignment, feature-flag evaluation, authentication from a signed token, and personalisation applied to an otherwise cacheable page — which is the strongest case, since it preserves the cache hit rate while delivering the personalisation.

What stays at the origin

Anything depending on shared mutable state. Writes, transactions, anything requiring consistency, anything computationally substantial, and anything needing a library the edge runtime does not support.

The deployment hazard

A change reaching every location in seconds means anything that can push a fix everywhere can push an outage everywhere. That requires validation before propagation, staged rollout by region with automated halt, and a rollback path that does not depend on the same pipeline.

The configuration split that must exist

Ordinary configuration cached indefinitely with a fail-to-last-known-good posture; security-critical revocation on a separate short-TTL, fail-closed channel — kept small so frequent fetching is affordable and failing closed is safe.

One channel for both means either revocation is slow or a control-plane outage becomes a customer outage, and the choice between those is not one anyone would make deliberately.