Edge Computing

The CDN chapter at the start of this course described edge locations purely as caches: serve a static file from a nearby site instead of traveling to the origin. Edge computing takes the same geographic idea and adds real computation to it. What if the edge could run actual code, not just hand out stored files? Then more of each request could be dealt with close to the user, and only the requests that truly need the origin would travel to it.

A retail chain has a central warehouse (the origin) a long way away, and a shop in your neighborhood (the edge). The shop can hand you items it has in stock, which is caching. But a shop assistant who is allowed to make small decisions can do more: check your membership card, apply the weekend discount, point you to the right counter. Only unusual requests need a call to head office. The more the assistant can decide, the fewer calls travel the long way.

• -The head office and warehouse are the origin servers.
• -The neighborhood shop is the edge location.
• -Handing out stocked items is edge caching.
• -The assistant making small decisions is an edge function: your code running at the edge.

Edge functions (Cloudflare Workers and AWS Lambda@Edge are examples) let you run JavaScript or similar code at hundreds of locations around the world. Good uses are cheap, stateless decisions made before a request goes anywhere near the origin:

• -Authentication checks: verify a signed token, as the auth chapter described, and reject bad requests without troubling the origin.
• -A/B test assignment: choose a variant by hashing a cookie, and route accordingly.
• -Redirects and rewrites: send users to a country's site, or fix up headers and URLs.
• -Light personalization: insert the user's name into an otherwise cached page.
• -Blocking bots and abusive traffic early.

Say a user in Mumbai talks to an origin in Virginia, and reaching the origin costs about 150 ms. A request answered at the nearby edge takes about 10 ms. Without edge computing every request pays the 150 ms. Now suppose the edge can fully answer 70% of requests, through its cache, auth checks and redirects, and the remaining 30% still go to the origin. The average becomes 0.7 x 10 + 0.3 x 150 = 7 + 45 = 52 ms, about a third of the original. The tail benefits too, because the slow, long-distance trip is taken far less often.

The diagram shows the idea: cheap, stateless checks happen near the user, and only requests that need it travel to the origin.

• -Tight limits: edge runtimes allow only a few milliseconds of CPU time, a small amount of memory, and a restricted set of APIs. Heavy computation does not fit.
• -No local state: any one edge location might not handle your user's next request, so you cannot keep session data there. State has to come from the request itself, from the origin, or from an edge key-value store.
• -Data is the hard part: those edge key-value stores replicate to hundreds of locations and are eventually consistent, so a write may take seconds to appear everywhere. They suit configuration and rarely changing data, not a bank balance.

The rule of thumb: logic that is cheap and stateless belongs at the edge. Anything that needs strong consistency, heavy computation or a lot of data stays in the origin region.