Section 3: Two Hundred Bids a Second Is Not the Problem - Scale Estimation & Workload Analysis

Executive Summary: This section derives every number the rest of the module cites, once, step by step. From 100 million live auctions and 25 million daily users we reach 14.3 million creations and closes a day, 100 million bids a day, and a system-wide peak of 5,000 bids per second - a calm figure. The hottest single auction, #7731 in its final ten seconds, puts 200 bids per second on one row against a 500 per second ceiling - warm, not hot. The brutal numbers live elsewhere: an uncoalesced fan-out of 10 million push messages per second for one item, and a 1,600 closes per second burst at 7 p.m. The lesson is the section's refrain: design for the shape of the load, not its total.

Section 2 left you holding one invariant and a deadline. The interviewer caps the marker and asks the question that prices both:

"Before you draw anything - how big is this?"

The weak answer is "it's eBay, so enormous," followed by a queue. The Staff answer is a chain of multiplications spoken aloud, because a number you derive is a number that can forbid a component - and here the arithmetic forbids most of what candidates reach for first, then points at two places they rarely look.

The Inputs You Agree On

Six facts, confirmed before any division happens. 130 million active buyers a year and 25 million daily active users. 100 million live auction-format listings at any moment, averaging 7 days each. Bids per auction: mean 7, median 2 - a heavy tail, and the tail is the whole story. Watchers per auction: median 4, with the agreed stress case of 50,000 watchers and 5,000 distinct bidders on one item. 2 million concurrent viewers holding an open item page at evening peak. 40 auction page views per daily user per day.

You: "I'll take those as given and derive everything else, so if one input is wrong you can see exactly which outputs move."