Section 3: Two Orders of Magnitude Before You Draw a Box - Scale Estimation & Workload Analysis

Executive Summary: This is the only section that derives numbers; every later section cites them — 333 thousand location writes a second, a fan-out chain that two filters cut from 133 million messages a second to 13.3 million and then 1.3 million, about a gigabyte of live state, and a declined history worth 2.9 terabytes a day.

The interviewer gives you one number and nothing else: "Assume a large social app — a billion registered users." Most candidates treat estimation as a tollbooth — "millions of QPS" — and hurry on to the boxes. Here it is the design: one result below eliminates an entire architecture, another says this is a messaging problem, not a storage one.

From a Billion Registrations to a Third of a Million Writes

Shrink the population honestly — a billion registrations are not a billion sharers. Nearby Friends is opt-in, and opt-in features get modest adoption: assume 10 percent turn it on → 100 million users with the feature enabled. Only the people live and sharing right now generate load; call that 10 percent at peak → 10 million concurrent active sharers. State both percentages as assumptions the interviewer can push back on; the stating is what is scored.

Each active sharer posts once every 30 seconds — a battery-driven cadence, revisited at the end of this section:

• 10 million concurrent ÷ 30 seconds = 333 thousand location updates per second at peak
• Peak-to-average for a consumer social app runs about three to one → roughly 111 thousand updates per second on average
• Daily total: 333 thousand × 86,400 seconds ÷ 3 ≈ 9.6 billion location updates per day

A third of a million writes a second is serious but not exotic — a horizontally partitioned in-memory tier absorbs it without drama. The twist: each write may have to become many messages.