What edge runtimes actually change about request handling

Most writing about edge runtimes argues about latency. Latency is the least interesting difference. The consequential changes are to execution model and lifetime, and they invalidate assumptions that traditional server code makes without stating them.

Process lifetime is not request lifetime

A long-running server process lets you cache in module scope, keep connection pools warm and schedule background work after a response is sent. An isolate may be evicted between any two requests, and may serve requests in several locations at once. Module-scope state is therefore a cache with no eviction guarantee, not a store.

Work after the response needs to be declared

Starting a promise and not awaiting it is a common pattern for logging or analytics. On an edge runtime the isolate may be torn down as soon as the response is returned, and that work is simply lost. It has to be handed to the runtime explicitly so it knows to keep the isolate alive.

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const response = await handle(request, env);

    // Not `void recordMetrics(...)` — an un-awaited promise is not a promise
    // the runtime knows about, and the isolate can be discarded before it
    // settles. waitUntil is what keeps it alive.
    ctx.waitUntil(recordMetrics(request, response, env));

    return response;
  },
};

None of this is exotic. It is the ordinary consequence of a different execution model, and it is worth internalising before rather than after the first production incident.