V8 Isolates

The Isolation Ladder

 how runtimes isolate untrusted code, by weight:

 VM (virtual machine):    full guest OS per tenant
                          boot: seconds-minutes   footprint: GBs
 CONTAINER:               shared kernel, isolated userspace
                          boot: 100ms-10s         footprint: 100s of MB
 PROCESS per request:     fork/exec per task
                          start: ~ms              memory: heavy per unit
 V8 ISOLATE:              sandboxed JS/WASM context INSIDE one process
                          start: ~0.5ms           footprint: ~MBs

 isolates are ~1000x faster to start than containers —
 the property that makes per-request serverless economics work.

What an Isolate Actually Is

 V8 = Chrome's JavaScript engine (also powers Node).

 an ISOLATE = a V8 instance with its own:
 - heap (garbage-collected JS objects)
 - compiled code caches
 - microtask queue / event loop

 many isolates share ONE OS process:
 [process: workerd-like runtime]
   ├─ isolate: customer A req#1
   ├─ isolate: customer B req#1     ← heap-level isolation;
   ├─ isolate: customer A req#2       no shared JS objects
   └─ ...

 security boundary: V8's sandbox guarantees heap separation.
 what's NOT inside: no raw sockets, no fs, only platform APIs —
 capability-based surface shrinks attack area further.

Why Cold Starts Vanish

 container cold start checklist:
   schedule pod → pull image → cgroup/namespace setup →
   runtime init → app init → listen          (~seconds)

 isolate "cold" start:
   allocate context in EXISTING process →
   load+compile script (often cached) → run   (~sub-ms)
 
 platforms pre-warm processes with loaded runtimes across POPs;
 new request = new isolate = effectively instant.
 traffic spikes don't queue behind provisioning —
 they just... execute.

The Resource Model

 per-isolate caps define the programming reality:

 CPU time:      milliseconds-scale budgets (per request, not wall-clock)
 Memory:        tens-of-MB heaps typical
 Startup size:  script bundles ≤ a few MB
 No threads:    single-threaded event loop per isolate;
                concurrency via async I/O

 design consequences:
 - async everything (I/O-bound patterns thrive)
 - heavy computation → WASM modules or offload to regions
 - native deps impossible → pure-JS/WASM dependency diet

Multi-Tenancy Economics

 thousands of isolates per machine → density → cheap per-request:

 cost per request ≈ CPU-ms used + amortized process overhead
 vs container-per-tenant models paying RAM for idle tenants.

 this density is WHY edge platforms bill per-request/per-cpu-ms
 and can scale-to-zero profitably. the isolation tech IS
 the business model.

Interview Framing

“Why don’t edge platforms just use containers?” is the probing question. Scored answer walks the ladder (VM→container→isolate), quantifies start-time deltas (~1000x), explains heap-level isolation + capability-restricted APIs as the security story, and lands the density-economics point. Knowing V8-isolate specifics (single-thread loop, WASM escape hatch for CPU work) completes the picture.