Section 3: Three Constraints Walk Into a Fleet - Scale Estimation & Workload Analysis

Executive Summary: This section derives, on stage, every number the rest of the design will spend. From one stipulated figure — 500K operations per second across a shared internal platform — we unfold the read/write split, the peak multiplier, the payload envelope, the dataset-versus-churn distinction, and the latency and durability targets. The centerpiece is the three-constraint fleet sizing: storage, read throughput, and write throughput each demand a node count independently, and the 401 lesson is knowing which constraint binds — and noticing when growth will flip it. We close by surfacing the one number that refuses to average out: a single key read 100K times per second.

Section 2 ended with a table full of promises. The interviewer now taps it: "You've committed to p99s and nines. Sized against what?" At the application tiers below 401, estimation is often a warm-up ritual — compute a QPS, nod, move on. For infrastructure, it is the design. Every number you derive in the next ten minutes becomes a budget that some mechanism in Sections 5 through 11 must pay, and the candidate who hand-waves here is the Single-Node Thinker in embryo: great engine, no idea how many engines.

The interviewer stipulates the anchor: this is a shared internal platform serving many product teams — the checkout team's carts, the flags team's configuration, a dozen tenants Mira hasn't met yet. Aggregate load: 500K operations per second on average.

From One Number to a Workload Shape

Start with the split. Key-value platforms skew read-heavy — most tenants write a value occasionally and read it constantly — so we take the classic 80/20 read-write split:

• Reads: 500K × 0.8 = 400K reads/s average
• Writes: 500K × 0.2 = 100K writes/s average

Averages size nothing. A platform absorbs every tenant's peak at once — a product launch, a flash sale, a Monday morning — so we apply a ×3 peak multiplier:

• Peak reads: 400K × 3 = 1.2M reads/s
• Peak writes: 100K × 3 = 300K writes/s

Why ×3 and not ×10? Because tenants peak at different times, and aggregation smooths the spikes — that is half the business case for a shared platform. A single-tenant service might budget ×10; a fifty-tenant platform that budgeted ×10 would run at 20% utilization forever. Say this reasoning aloud: the multiplier is a judgment call, and the interviewer is scoring whether you know it's one.

Quick check before moving on: