Study guide 29 of 183

Edge computing

Running code and data close to users: edge functions at CDN locations, use cases such as auth, routing, personalisation and A/B assignment, edge key-value stores and their consistency, latency gains and limits, data residency, and what should stay in the origin region.

Reading is half of it. See this used in a real interview: walk through Design a URL Shortener →

CDNs started by caching files near users. Today they also run code at hundreds of edge locations, a few milliseconds from most people, with small data stores beside it. For some requests that means the whole response can be produced without a trip to a distant origin region. For interview designs with global users and tight latency (URL redirects, typeahead, personalised pages), edge computing is a useful tool, provided you know its limits.

What runs at the edge

Edge functions (lightweight runtimes started in milliseconds at CDN points of presence) can inspect and modify requests and responses, or generate responses themselves. Typical uses:

Routing and rewriting: send users to the right region, version or backend; A/B test bucketing; redirects. See global traffic management.
Authentication checks: verify a signed token or cookie before the request travels further; reject bad requests early. See JWT vs session cookies.
Rate limiting and bot filtering close to the source. See rate limiting algorithms.
Personalisation of cached pages: assemble a cached page with small personalised fragments, or choose a variant by country, language or experiment group.
Image and media transformation on the fly (resize, format conversion), cached afterwards.
Simple APIs answered from edge data: redirects, feature flags, configuration, geolocation lookups.

Data at the edge

Edge platforms provide storage near the functions:

Edge key-value stores: globally replicated, very fast reads; writes propagate in seconds (eventually consistent). Good for configuration, redirects, feature flags, read-mostly lookups.
Edge caches with programmable keys and purges. See HTTP caching.
Coordinated state objects offered by some platforms: a single instance per key, located somewhere in the network, providing strong consistency for that key (useful for rate limiters, rooms, counters) at the cost of requests travelling to that instance.
Replicated SQL read replicas near users with a primary elsewhere.

The constant trade-off: reads can be local; consistent writes cannot. A write must reach a single authority somewhere, which for global users is far away for many of them. See consistency models.

The latency gain

If the origin is in one region, users on the other side of the world pay 150 to 250 ms per round trip, and several round trips for new connections. Answering at the edge cuts that to 10 to 30 ms. But if the edge function then calls the origin anyway (for a database query), little is saved, and sometimes it is worse (an extra hop). Edge compute pays off when the response can be produced from edge data and caches, or when it filters requests that would otherwise travel. See latency numbers.

Limits

Constrained runtimes: limited CPU time per request, memory, and APIs; not every library runs there.
No heavy computation or large data: the data lives in regions.
Debugging and observability across hundreds of locations need good tooling.
Consistency: edge data is usually eventually consistent; design for it.
Cost per request can exceed origin costs for heavy logic.

Data residency

Edge functions run wherever the user is, which is good for latency and tricky for compliance: personal data processed at the edge may cross borders. Keep personal data processing in the user's home region, or restrict which locations handle certain requests. See privacy and data deletion.

Examples

URL shortener: redirect mappings replicated to an edge key-value store; the edge function answers redirects in milliseconds worldwide and logs clicks asynchronously. New links take seconds to propagate, which is acceptable. See Design a URL Shortener.
Typeahead: popular prefix suggestions cached at the edge; personalised suggestions fetched from the region. See Design Typeahead.
Streaming: the edge chooses the CDN, signs URLs, and applies regional catalogue rules. See Design Netflix.
Rate limiting: approximate per-location limits at the edge, exact limits in the region. See Design a Rate Limiter.

What stays at the origin

Transactions, writes that need strong consistency, heavy business logic, large datasets, machine learning inference on big models (unless edge GPUs are available), and anything requiring joins over large data.

In the interview

"Redirects are answered by edge functions from a globally replicated key-value store, so 99 % of traffic never reaches the origin; creation goes to the primary region, and new mappings propagate to the edge within seconds." It is a short, concrete improvement for any global, read-heavy, latency-sensitive path.

Checklist

Edge functions for routing, auth checks, rate limits, personalisation and simple lookups.
Edge key-value stores for read-mostly data; writes go to a single authority.
Gains only when the request avoids the origin.
Runtime limits and observability planned for.
Residency rules for personal data processed at the edge.
Transactions and heavy work stay in regions.