Resource Estimation

In one line: this lesson estimates the same quantity twice, in two different units, and never notices. Finding the contradiction is a better exercise than any of the individual calculations.

Assumptions

• 178 million unique users
• 60 million daily active users (DAU)
• 500 million places

Number of servers

Considering our assumption of using daily active users as a proxy for the number of requests per second, we get 60 million requests per second.

Servers needed at peak load = (Number of requests/second) / (RPS of server)
                            = 60,000,000 / 64,000
                            = 937.5, so about 1,000 servers

The course's DAU-as-RPS convention, and what it is worth

This substitution is the course's own stated shorthand from the back-of-the-envelope chapter, and that building block used it identically (32M DAU became 500 servers). So it is a convention, not a slip — unlike that building block, where the prose and the arithmetic disagreed.

Still, be clear about what it assumes. Treating 60 million DAU as 60 million requests per second means every daily active user is issuing a request every second, continuously, all day. That is not a peak-load safety factor; it is roughly 86,400 times the traffic those users generate.

The defensible reading is that it is a deliberately crude upper bound — provision for the absurd case and you will never be short. The indefensible reading is that anyone believes it.

Where it does real damage is that it hides the actual number, and the actual number is interesting: the fleet is sized by hotspots and by index memory, not by aggregate request volume. We will get to the real figure in a moment, because this same lesson computes it.

Storage

The 0.54 GB estimate covers only one day of reviews. For 10-year storage, this increases to approximately 2 TB (0.54 GB × 365 × 10), bringing the total requirement to ~2.8 TB.

All of these reproduce exactly.

Under 3 TB — which tells you storage is not the problem

The whole platform — 500 million places, 178 million users, a decade of reviews — fits in under 3 terabytes.

Put that beside the rest of the course: YouTube's chapter estimated petabytes of duplicate uploads alone, Quora 42 PB per year, Google Maps about 20 PB of map data.

Yelp is four orders of magnitude smaller, and the reason is that it stores metadata about places, not the places themselves. A place is a name, a description, and two coordinates. The 3 MB photograph is a path in this schema — 256 bytes pointing at blob storage — which is exactly why the Photos table is 280 bytes rather than 3 MB.

That is worth naming as a technique rather than an accident. Keeping large objects out of the primary store and holding only references is what lets the metadata database stay small enough to index aggressively and replicate cheaply. It is the same separation object storage argued for, and here it is the difference between a 3 TB database and a 1.5 PB one.

So: storage is not a constraint. The design's difficulty is entirely in the index, and the index turns out to be smaller still — 12 GB, as Lesson 11 will compute.

Bandwidth

Incoming assumes 5 new places per day (1,296 bytes plus a 3 MB photo) and 1 million new reviews per day (537 bytes each):

Places  = 5 x (1,296 + 3 MB)     = 15,006,480 bytes/day
Reviews = 1,000,000 x 537        = 537,000,000 bytes/day
Total   = 552,006,480 / 86,400   = 6.39 KB/s = 51.12 Kb/s

Outgoing assumes each search returns 20 places, each with a 3 MB photo:

One search = 20 x (1,296 + 3 MB) = 60,025,920 bytes
Per second = 60,025,920 / 86,400 = 0.69 KB/s = 5.52 Kb/s
x 60 million DAU                 = 331.2 Gb/s

Here is the contradiction — the same 60 million means two incompatible things

Look at what the outgoing calculation actually does. It takes one search response — 60 MB — and divides it by 86,400, the number of seconds in a day. Then it multiplies by 60 million users.

That arithmetic is only meaningful if each daily active user performs one search per day, and that search's bytes are smeared across all 86,400 seconds.

But two sections earlier, the server calculation asserted that 60 million DAU means 60 million requests per second.

Server section:     60M DAU  =>  60,000,000 requests per SECOND
Bandwidth section:  60M DAU  =>  60,000,000 requests per DAY
                                 ------------------------------
                                 the same number, 86,400x apart

Both cannot be true, and they are two sections of one lesson. If the server section's premise held, the outgoing bandwidth would not be 331 Gb/s — it would be 86,400 times larger, roughly 28 petabits per second, which exceeds the entire internet.

The internally consistent reading is the bandwidth one: 60 million searches per day is about 694 requests per second, which needs a fraction of one server at 64,000 RPS. The server figure of 1,000 is the outlier.

This is a sharper version of the error in that building block. There, the prose and the arithmetic disagreed and one was clearly a slip. Here two complete calculations disagree, each internally sound, and the lesson presents both without noticing.

The transferable habit is small and worth adopting: when the same input quantity appears in two calculations, check that it means the same thing in both. A units mismatch that survives one section usually does not survive being asked to agree with the next one.

A 60 MB search response is the more practical problem

Set the contradiction aside and look at the payload the outgoing figure assumes:

20 places x 3 MB per photo = 60 MB per search

Sixty megabytes to display a list of cafes. On a phone, on cellular, to answer "what's nearby."

And it contradicts the API design in the next lesson, which says each search result carries "the place name, address, category, rating, and thumbnail." A thumbnail is tens of kilobytes, not three megabytes.

Sizing with full-resolution photos where the API returns thumbnails inflates the outgoing estimate by roughly a hundredfold. With 50 KB thumbnails, a search response is about 1 MB, and outgoing bandwidth falls from 331 Gb/s to a few gigabits.

Three things worth saying about this:

It changes what infrastructure you need. 331 Gb/s of image traffic is a CDN problem demanding serious edge capacity. A few Gb/s is not.

The images should be on a CDN regardless, served directly from blob storage rather than through the application tier — which the design supports, since the database holds only paths.

Serving thumbnails and full images is a deliberate tiering decision, exactly like object storage's access tiers. The list view gets thumbnails; the detail view, which one user in twenty reaches, gets the full image.

An interviewer who hears you notice that the response size and the API contract disagree learns more about you than one who hears the number recited.

Building blocks

The chapter also explicitly references the Google Maps design for location-based search.

The block list is short because the interesting component is not reusable

Four blocks, all familiar. Compare that building block's ten components or that building block's twelve.

The reason is that this design's distinguishing component — the quadtree server — is not a building block at all. It is a data structure held in memory, built by this system for this purpose.

That is a useful signal about where to spend interview time. The load balancer and blob storage need one sentence each. The index needs ten minutes, and the fact that it is not on the building-block list is exactly why.

Both numbers point the same way, and the useful move is to state what they rule out. A terabyte fits comfortably in a single instance, and one write per second is trivial for any relational database — so sharding and message queues are complexity without benefit here.

Interview signal by level

Next: the API, and what its parameters reveal about the query.