Section 2: Promises With Milliseconds Attached - Requirements (Functional & Non-Functional)
Executive Summary: This section turns Section 1's assumptions into a contract. The functional list covers the function lifecycle: upload, immutable versions behind aliases, three ways to invoke, concurrency controls, and per-millisecond billing. The non-functional list is where the design gets decided, and the senior move is to split it in two. The data plane (every invoke) promises 99.95% availability, warm overhead p99 ≤ 10 ms, cold-start overhead p50 ≤ 150 ms / p99 ≤ 500 ms, cold starts on ≤ 1% of invokes region-wide, and growth of +1,000 concurrency every 10 s per function. The control plane (deploys and config) promises 99.9% and config propagation within 5 s. We then defend two refusals: no zero cold starts, no exactly-once.
The interviewer sets down the marker: "Good. Now tell me what this platform actually promises a customer." The Staff answer starts from who feels each failure. When checkout-api stalls during Tidewater's 09:00 flash sale, shoppers abandon carts. If a PublishVersion call fails, a Tidewater engineer clicks retry. Those two failures don't cost the same, so they shouldn't get the same promise.
The Functional Contract
Each item is here because a later section builds it:
- Create and update functions. Code arrives as a zip (managed runtimes such as Node.js 22 or Python 3.12) or as a container image up to 10 GB. Configuration covers runtime, handler, memory (128 MB to 10 GB, with CPU scaled at 1 vCPU per 1,769 MB), timeout (max 15 min), environment variables and an execution role.
- Immutable versions and aliases.
PublishVersionfreezes code and config into a numbered version (checkout-apiis on version 42). An alias such asliveis a pointer that can be moved, or weighted across two versions for a canary. Section 4 defines the calls. - Synchronous invoke. Request in, response out, payloads up to 6 MB each way. A function's own error is reported separately from a platform error.
- Asynchronous invoke. The platform accepts an event up to 256 KB, returns 202, and runs it later with 2 retries and backoff, a max event age of up to 6 h, then an on-failure destination such as a dead-letter queue.
thumbnail-makerlives here. - Event-source mappings. Platform-run pollers read a customer's queue or stream, batch records, and invoke the function, preserving per-shard order.
- Concurrency controls. An account limit (default 1,000 concurrent, raisable to tens of thousands), reserved concurrency per function (a guaranteed share and a cap), and provisioned concurrency per version or alias (sandboxes initialized ahead of traffic).
- Metering. Duration billed in 1 ms increments times configured memory.
- Logs and metrics emitted. Every invoke emits logs, duration, errors and throttles. Log storage is a separate system we feed.
Out of scope, with reasons: VPC networking, edge functions, durable workflows, response streaming and GPUs (Section 12 follow-ups the core must admit), multi-region (one region here; Section 11), jobs over 15 minutes (a batch product), and local state beyond /tmp (functions are stateless).
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