Edge Computing

For a long time all of a service's computation happened in one place. With servers in the eastern United States, a request from Seoul crossed the Pacific and came back. That round trip alone costs about 200 milliseconds. If drawing a single screen needs four or five of them, a full second disappears before any code runs, and no amount of optimization brings it back. The speed of light around the planet is fixed.

Files got solved first. A content delivery network (CDN) copies assets that go out identically to everyone — images, scripts, stylesheets — to locations around the world in advance, so a visitor in Seoul gets them from a Seoul location in about 10 milliseconds. What stayed slow was everything that differs per person. Checking whether someone is signed in, sending them to a page in their language, splitting them into an experiment group: none of that can be copied ahead of time, so all of it stayed at the center.

The same meeting kept repeating itself. Someone brings a chart showing that visitors in Asia drop off more, everyone goes hunting for the slow part, and neither the code nor the database has one. The only remaining answer is distance, and the only known fix was standing up a full copy of the stack in every region. That triples what there is to operate, and starts a separate argument about which copy of the data is authoritative.

Edge computing moves the deciding part outward instead of moving the whole server. Locations holding cached files already exist everywhere, so the idea is to let a little code run in those same locations.

Start by picking which slice of the central server's work goes out to those locations. From there it is five steps.

1. Choose what moves. Small input, fast answer. Reading a cookie to see whether someone is signed in, redirecting by country, assigning someone to a test group — all of these qualify.
2. Rewrite that slice for the edge runtime. These runtimes are not ordinary servers and they come with limits: usually tens of milliseconds of execution per request, memory in the neighborhood of 128 megabytes, and no writing files to keep around.
3. Deploy. One upload replicates the same code to every location automatically. Not uploading per region is the part that differs most from running regional copies of a full stack.
4. Write the routing rules that decide which requests the locations handle. Requests starting with /api go to the center, everything else gets answered at the edge.
5. Measure response time per region. A global average hides the effect, so look at Seoul, Frankfurt and São Paulo separately — the places far from the server. If those numbers don't move after the change, distance was never the cause.

Not calling a database from the edge is the premise holding the whole procedure together. Whatever the decision needs either rides along in the request itself or sits at the location as cached state. One call from a location back to the central database restores exactly the round trip the move was meant to remove.

It fits where the decision is short and that decision gates the speed of everything else on screen. Checking credentials and turning away people who shouldn't get in, branching to a different language version by region, splitting traffic for an experiment. The result differs per person while the computation itself takes about a millisecond, so keeping it central means waiting 200 milliseconds to receive a one-millisecond answer.

Three kinds of work do not belong there.

1. Anything whose data lives only at the center. A screen that has to read order history will call the center anyway, so nothing gets shorter.
2. Heavy computation. Image transcoding or large aggregations hit the execution time limit first.
3. Work where ordering and consistency matter. Payments or inventory decrements have to happen exactly once, and accepting them at many locations at once makes that hard to guarantee.

Operations pay something too. When something breaks, the first question is which location it broke at, and reproducing it on a laptop is awkward. Like serverless functions, edge runtimes sleep when idle, so cold start delay on the first request comes along with them. The runtime is lighter than a full serverless container, which keeps that delay shorter than the usual case, but it doesn't vanish.

"Let's push this redirect to the edge. Crossing to the center for it is a waste."

One decision is spending a full round trip, so it should be answered at a nearby location instead.

"You can't call the database from the edge. Put the values you need into the token."

Edge code cannot read central data, so the request has to carry what the decision requires.

"The US numbers are flat, but Asia dropped 400 milliseconds."

A result report — the farther a region sits from the server, the larger the gain.

Pagedeck's servers run in the western United States. Theo pulled response times by region and found that the first screen took 1.4 seconds in Seoul and Singapore against 0.5 seconds in the US. Nothing in the code was slow. Almost all of the gap came from one decision at the very start: checking whether the visitor was signed in and sending them to their workspace address. That single check was crossing the Pacific.

Theo moved only that check outward — thirty lines that pull a token from a cookie, verify it, and redirect. The day after deploying, first-screen time in Asia dropped to 0.9 seconds and the US figure stayed where it was.

Reading it as "anything runs faster at the edge" is the most common mistake, and the phrase "closer to the user" invites it. The only thing that shrinks is network round trip time, and the moment edge code calls the central database, that round trip comes back. Move a data-reading handler out there and the number of round trips goes up instead of down, leaving the page slower than before plus a new layer to operate. Check whether the handler needs central data before moving it, not after.

The other frequent assumption is that the central server becomes unnecessary. What runs at a location is a decision made at the door; storing orders and reading history stays at the center exactly as before. Adopting edge computing subtracts nothing from the list of things to operate — it adds one. Whether that price is worth paying comes down to how many visitors sit far from the server. If most of them are in the same country as the servers, there is very little to win.