Serverless at the Edge

The Model

 traditional: you run N servers, patch them, scale them, pay 24/7
 edge serverless:
   - deploy CODE (a function/handler)
   - platform replicates it globally, executes per request
   - billing per usage; idle costs ~nothing
 
 you manage: code, config, observability
 platform manages: fleet, placement, scaling, isolation,
                   TLS, hardware failure replacement

The Execution Shape

 export default {
   async fetch(request, env, ctx) {
     // runs at the POP nearest the user
     const cache = caches.default;
     let res = await cache.match(request);
     if (!res) {
       res = await fetch(request);        // or compute/auth/etc.
       ctx.waitUntil(cache.put(request, res.clone()));
     }
     return res;
   }
 }

 characteristics defining the runtime class:
 - ISOLATES not containers: V8-class contexts, ~0ms cold starts
 - PER-REQUEST limits: CPU ms, memory MB, bundle KB
 - GLOBAL by default: same code everywhere simultaneously

Cold Starts: Solved (Mostly)

 region serverless (Lambda-class):
   cold start = provision container + init runtime ≈ 100ms-1s+
   → provisioning games (provisioned concurrency) needed

 edge isolates:
   cold start = spin an isolate ≈ 0-5ms
   → effectively no cold-start problem; p99 unaffected by traffic gaps

 this single property is why edge platforms serve
 spiky interactive traffic that Lambda-class platforms handle
 with pre-warming gymnastics.

Scale-to-Zero and Its Consequences

 midnight: zero requests → zero cost ✓
 flash-mob: 1M req/s → platform fans out across POPs automatically ✓

 consequences teams underestimate:
 - NO CAPACITY PLANNING for the tier itself... 
 - ...but DOWNSTREAM still needs it: your database sees
   every request eventually. unlimited edge scale +
   finite origin = the stampede problem with new clothes.
   keep caching/shedding discipline at edges!

State and Storage Models

 serverless functions are stateless by construction. state options:

 - external KV/cache APIs (platform-provided, edge-local reads)
 - durable object / actor primitives: single-owner stateful
   entities with strong consistency (the stateful escape hatch)
 - regional databases via HTTP/poolers (watch connection storms)
 - R2/blob storage APIs for files

 the KV-at-edge pattern: reads served from replicated store
 (~ms), writes go to a primary region — eventual consistency
 with read-your-writes handled via version stamps.

When Edge Serverless Fits

 ✓ global request routing/auth/personalization logic
 ✓ API gateways + transformation layers  
 ✓ spiky or unpredictable traffic (scale model matches)
 ✓ teams without infra operations capacity

 reconsider when:
 ✗ long-running jobs (timeouts) → queues/workers instead
 ✗ heavy consistent-state apps → regional services + actors
 ✗ deep native dependencies → container platforms

Interview Framing

“Should this be edge serverless?” scored evaluation covers: latency-sensitivity of the logic, statelessness fit, cold-start irrelevance (isolate vs container distinction), downstream-capacity caveat (“edge scales; your DB doesn’t”), and cost model fit (per-request vs reserved). Naming the isolate-vs-container cold-start difference is the technical depth marker.