Section 12: The Core Holds Still - Follow-up Feature Evolution

Executive Summary: The interviewer turns product manager with seven features: snapshot starts by default, response streaming, durable workflows, multi-concurrency, GPU functions, edge functions and VPC networking. A Staff candidate doesn't design seven platforms. Each feature gets four questions: what changes, what stays, which earlier decision left the door open, and which flip trigger fires. Five arrive through existing seams: immutable versions, content-addressed chunks, the lease, the stable eventId, and concurrency enforced at placement. Edge and GPU are honestly new products that share the control plane.

Interviewer: "It shipped and it held through the flash sale. Here's next year's roadmap: snapshot starts for everyone, streaming responses, workflows, more than one request per sandbox, GPUs, edge, and customer VPCs. What does this do to your design?"

You: "Less than it sounds. For each one I'll name the seam it plugs into and whether it fires a flip trigger we wrote down. If a feature fits no seam, I'll call it a new system."

Key Insight: None of these was built early. Each fits because a decision made for its own reasons left a clean seam. Not blocking the future is cheap; building it on speculation is usually waste.

Snapshot Restore by Default: D6's Flip Trigger Fires

Snapshot restore shipped opt-in (D6): initialize a version once, snapshot the microVM's memory, and restore copies in ~100–200 ms, rescuing JVM functions whose init takes seconds. The flip trigger was named: make it the default once uniqueness is handled.

What stays. Versions are immutable, so a snapshot is one more content-addressed artifact keyed by the version's config_hash (code digest plus runtime, memory and settings). It lives in the same chunk store, caches in the same AZ and host tiers, loads lazily like a 10 GB image, and never needs invalidating (D10).

What changes. Every restored copy is a clone of the same memory: the same RNG state, the same "unique" IDs generated at init, the same cached credentials, and the same TCP connections, now dead. So the platform adds before-snapshot and after-restore hooks, and the VMM signals the guest on restore so it reseeds its entropy. Customer code uses the after-restore hook to rebuild connection pools, which is where Tidewater's ~200 ms of DB-pool init moves. Default-on ships runtime by runtime, as each runtime's hooks land.

Quick check before moving on: