Section 3: Sized for the Worst Day, Not the Average One - Scale Estimation & Workload Analysis

Executive Summary: 30 M holiday shoppers produce about 25,000 requests/s at peak, and fan-out to N = 3 replicas turns that into 75,600 replica ops/s. Storage (68 GB per node) and network (≈ 6 MB/s per node) don't bind. Throughput after losing one of three data centers does: at 2,000 ops/s per node and a 90% ceiling it sets 66 nodes, 22 per DC, which run 57% busy normally and 86% with a DC dark. Every figure is our interview's assumption, not Amazon's real data.

The interviewer taps Section 2's requirements: "p99.9 under 300 ms at peak, and survive a data center. How many machines is that?" The trap is to size for the average and add redundancy afterwards. Here the failure case is the sizing case.

From Shoppers to Requests

You: "These are my assumptions, not Amazon's figures. The 2007 paper reports well over 3 million checkouts on a single holiday day, so I'll plan for an order of magnitude more people browsing than buying: 30 M active shoppers on the peak day."

You: "Every page renders the cart badge or mini-cart, so a shopper does about 20 cart reads a day. Adds, removes and quantity changes come to about 4 writes."

Interviewer: "So the store handles 25,000 operations a second?"

You: "The client sees 25,000. The nodes see three times that. The coordinator sends every get and put to all N = 3 replicas, though it waits for only R = 2 or W = 2. That lets the fastest two answer (Section 10) and lets a get spot a stale replica for read repair. Replica load is 21,000 × 3 = 63,000 reads/s plus 4,200 × 3 = 12,600 writes/s: 75,600 replica ops/s. That's what I size against."

Key Insight: R and W set how long the client waits, but N sets how much work the fleet does. Size a Dynamo instance from client QPS and you've under-provisioned it threefold before the first node fails.

Quick check before moving on: