Cold Starts at the Edge

Defining the Problem

 COLD START: extra latency on a request that finds no warm
             execution context ready.

 components (container-class platforms):
   scheduling + image pull      100ms-several seconds
   runtime/app initialization   10ms-seconds (framework boot!)
   first-connection setup       DB pools, cache connections...

 user impact: p50 fine, but the FIRST request after idle
 pays everything — tail latency spikes exactly when
 traffic is sparse (nights, new regions).

The Edge Advantage

 isolate-based edges attack every component:

 scheduling:    none — code resident in pre-warmed processes
 image pull:    script bundles ≤ MBs, already replicated to POPs
 init:          V8 isolate creation ~0.5ms; script compile cached
 connections:   platform-managed pools; your code stays stateless

 result: cold start ≈ 1-5ms → statistically invisible.
 p99 ≈ p50 for most edge workloads. THIS is the platform's
 core promise versus Lambda-style functions.

Residual Cold Paths That Remain

 "no cold starts" has asterisks worth knowing:

 1. SCRIPT COMPILE CACHE MISSES:
    brand-new deploy's first hits per POP pay parse/compile (~ms)
    
 2. DEPENDENCY INITIALIZATION:
    lazy-loaded WASM modules or big JSON configs fetched
    on first use → design eager init into deploy instead
    
 3. DOWNSTREAM CONNECTIONS:
    your code may be instant; the origin DB pool it opens
    isn't. keep TLS/session reuse at platform layer;
    avoid per-request connection churn in handlers
    
 4. KV/CACHE FIRST READS:
    eventually-consistent stores may not have propagated
    your latest deploy-time seeds everywhere YET

Warm-Up Strategies Where Cold Starts Persist

 for container-class serverless still in your architecture:

 PROVISIONED CONCURRENCY:  N containers kept warm; cost = always-on
 MIN INSTANCES:            same idea, different vendor spelling
 PINGER WARMING:           synthetic traffic keeps functions hot
                           (fragile; vendors discourage; still seen)
 SCHEDULE-BASED PREWARM:   scale up before known peaks (sales)
 LAZY-FRIENDLY DESIGN:     make cold path CHEAP — defer all init
                           until actually needed; split bundles

 architectural fix > infrastructure patches:
 smaller images + faster frameworks shrink cold starts
 more reliably than any warming trick.

Measuring Honestly

 instrument the distinction:
 - platform init time (their dashboards)
 - YOUR handler init time (first-run flags in logs)
 - downstream connect time (traces)

 alert on cold-rate × cold-cost product:
   rare colds on cheap endpoints: ignore
   frequent colds on checkout path: act immediately

Interview Framing

“Serverless sounds great but cold starts…” scored response: distinguish container-class (real problem, list mitigations) from isolate-edge class (sub-ms, effectively solved), then name the RESIDUAL paths honestly — dependency init, downstream connections, KV propagation. Candidates repeating “cold starts are dead” without asterisks reveal they’ve never operated it; naming the residuals shows you have.