Edge Computing

Definition

Edge computing executes logic at distributed points of presence — hundreds of locations rather than a handful of regions — so the user's request is answered without crossing an ocean. The trade is that edge runtimes are constrained: limited execution time, limited memory, restricted APIs, and no local durable state.

What belongs at the edge

• Routing and rewriting. Choosing an origin, normalising a URL, applying a redirect.
• Authentication and token validation. Rejecting an invalid request 5 ms from the user rather than 150 ms away.
• Personalisation of cached content. Assembling a cached page with a small user-specific fragment, so the expensive part stays cacheable.
• A/B assignment, so the variant decision does not require an origin round trip.
• Rate limiting and bot mitigation, which are far more effective near the source of the traffic.
• Image transformation and format negotiation, serving the right rendition per device.

What does not

Anything requiring strongly consistent shared state, anything requiring a large working set, and anything whose logic changes on a cadence that would make deploying to hundreds of locations a liability rather than an asset.

Industry example

Cloudflare's edge platform is the clearest expression of the model, and the architectural point is about where the state lives, not where the code runs. Running code in 300 locations is straightforward; giving that code consistent data is the hard part, and the available answers are all compromises: replicate globally and accept eventual consistency, pin a piece of state to one location and accept the latency for whoever is far from it, or keep state at the origin and use the edge only for stateless work.

The second option — a single authoritative location per object, with edges routing to it — is underrated. It gives strong consistency per object and locality for the users who matter most for that object, which fits collaborative documents, game sessions and chat rooms well.

The DDoS case shows the same principle from the other side: mitigation works because it happens at every edge simultaneously, so attack traffic never converges. Centralised scrubbing requires the traffic to arrive somewhere first, which is the property being attacked.

Failure scenarios

• Business logic drifting to the edge, so critical behaviour lives in a runtime with limited debugging and a deployment model different from everything else.
• Edge state assumed consistent, producing subtle bugs that appear only for users in certain regions.
• Cold starts and per-request limits hit by logic that grew beyond what the runtime was for.
• A configuration change at the edge deployed globally in seconds, with no canary — the blast radius is every user at once.

Trade-offs

Bought: latency, resilience to origin problems, and mitigation close to the source of abuse. Sold: execution capability, state consistency, debugging ergonomics, and often portability.

Interview question

"Which parts of a personalised e-commerce page would you assemble at the edge, and where does the state for each live?"