Section 6: Two Planes and a Lease - High-Level Architecture
Executive Summary: This section turns Section 5's data model into components. The control plane holds durable truth and may be briefly unavailable. The data plane (front-ends, a partitioned in-memory placement service and microVM worker hosts) handles 1M invokes a second and never waits on the control plane. We trace a warm call to 110 ms of platform time), and an async checkout-api:live (under 10 ms of overhead at p99), a cold call (thumbnail-maker event that re-enters through the same invoke path. Then we defend direct front-end-to-worker calls, the missing async side door, and cells.
The interviewer hands over the marker: "You have the API and the data model. Draw me the platform." A weak answer draws fifteen boxes and narrates them left to right. A strong answer states the organizing idea first.
You: "Two planes, and one rule between them. The control plane holds durable truth: functions, versions, aliases, code. The data plane runs invokes and reads only pushed, cached copies of that truth. An invoke is three moves: a front-end authenticates and resolves config from memory, placement leases it one idle sandbox, and the front-end sends the payload straight to that worker host. The lease is the only coordination on the hot path."
The Whole Platform on One Whiteboard
| Component | Job | Scale (ledger) | When it fails |
|---|---|---|---|
| Front-end fleet | TLS, auth, config + alias lookup from memory, payload limits (6 MB sync, 256 KB async), coarse rate limit for DDoS only | Stateless; the load balancer drains it, clients retry | |
| Placement service | Leases idle sandboxes, counts concurrency, picks hosts for cold starts | 64 partitions region-wide ( |
Partition fails over; state rebuilt from worker reports in seconds |
| Worker hosts | Firecracker-style microVMs, host agent, pre-booted pool, NVMe code cache | ~3,150 hosts, ~600 sandboxes each, 1.26M resident at peak | Placement stops leasing to the host; its in-flight invokes fail |
| Async queue | Durable, replicated log across 3 AZs, partitioned by function | 1.25 GB/s ingest at peak (3.75 GB/s replicated) | 202 after a 2-of-3 AZ write quorum, so one AZ can be lost without losing accepted events |
| Pollers | Drain async partitions and customer queues/streams, invoke through the front door | ~208K invokes/s from ~2M records/s for event-source mappings | Leases expire, another poller resumes (so a few duplicates) |
| Metadata store | Strongly consistent truth for functions, versions, aliases, limits | ~600 writes/s at peak, ~2 GB of hot config | Control API fails; invokes continue on cached config |
| Code chunk store | Content-addressed, deduplicated chunks: customer code under its own key, platform runtimes and public layers stored once (Section 8) | ~400 TB stored, ~20 TB working set per AZ | AZ and host caches keep active functions running |
| Billing log | Per-minute pre-aggregated metering off the hot path | ~30 GB/day after ~100× aggregation | Hosts buffer and replay; invokes never block on billing |
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson