Resource Estimation

In one line: this estimation contains the most instructive error in the course, because the chapter does the calculation correctly and then discards its own answer two sections later.

Assumptions

1 billion registered users, with 500 million daily active users. An average user has 300 friends and follows 250 pages.

Traffic

Each daily active user opens the application 10 times a day:

500M x 10 = 5 billion requests/day
5,000,000,000 / 86,400 = 57,870 ~= 58,000 requests/second

That is correct, and the chapter even illustrates it with a figure reading "58k Requests/second." Hold onto it.

Storage

All four reproduce exactly. Two of them are measuring something other than what they claim.

The 56 PB counts the same video in hundreds of feeds

Look at what 112 MB × 500,000,000 actually computes: the media in every user's precomputed top-200 posts, summed over all users.

But a post appears in many feeds. If Alice and Bob both follow Carol, Carol's 2 MB video is counted twice. If a popular page has ten million followers, its video is counted ten million times.

Total feed slots = 500M users x 200 posts = 100 BILLION post-slots
Distinct posts   = far fewer

Suppose active users post once or twice a day:

So the real blob-storage requirement is a fraction of a petabyte per day, not 56 PB — the published figure over-counts by roughly two orders of magnitude.

Blob storage holds each object once. Feeds hold references to it. That is not a subtlety; it is the whole reason a feed is affordable. The Twitter chapter stated it as a rule: fan out references, not values.

And the chapter knows this — its own optional Q&A says:

"A more memory-efficient approach stores an index that maps each user_id to a list of recent post_ids... This avoids precomputing and storing complete feeds for every user."

That is exactly the correction, and it is buried in an expandable box rather than applied to the estimate that needed it. The estimate models feeds as containing copies; the design says they contain pointers.

When a storage estimate multiplies content by audience, check whether you are storing copies or references. Multiplying by audience is right for bandwidth and wrong for storage.

50 KB per user is about 250x too large

The schema in Lesson 7 shows exactly what a user record holds: User_ID, Name, Email, CreationDate, Mobile, LastLogin.

varchar(32) x 4 fields + 2 datetimes  ~=  150-200 bytes

At 200 bytes, a billion users is 0.2 TB — not 50 TB. The published figure is roughly 250 times a plausible row.

There is a defensible reading: "user metadata" might include denormalized activity history, preferences, and the interaction features Lesson 10's ranking service needs. Those genuinely could reach 50 KB per user, and they are real data a feed system stores.

But then it should be labelled as such, because it changes what the number is for. A 200-byte identity record is looked up on every request; a 50 KB behavioural profile is read by the ranking pipeline. Different sizes, different access patterns, different stores.

The habit worth taking: sanity-check a per-item size against the schema that defines it. The chapter provides both, two sections apart, and they disagree by two orders of magnitude.

Servers — and the contradiction

Based on our assumption that daily active users serve as a proxy for requests per second during peak load, we estimate 500 million requests per second.

500,000,000 / 64,000 = 7,812.5 ~= 8,000 servers

The chapter computed 58,000 RPS and then used 500 million — a factor of 8,640

This is the sharpest version of an error that has now appeared four times in this module, and it is the worst because the correct figure is in the same lesson.

Traffic section  (correct):    5B requests/day / 86,400  =  57,870 RPS
Server section   (asserted):                              500,000,000 RPS
                                                          ------------------
Contradiction factor:                                     8,640x

The traffic section did the division. There is even a diagram captioned "58k Requests/second." Then the server section discards it, substitutes DAU-as-RPS, and computes a fleet from a number the chapter has already disproved.

Substituting correctly:

57,870 / 64,000 = 0.9 servers

Less than one machine. Which is the real finding, and it is the same conclusion the Yelp, Uber, and ChatGPT chapters reached from their own corrected estimates: the classic server formula measures request handling, and request handling is never the bottleneck in these systems.

What actually sizes the fleet here is entirely absent from the estimate:

• Fan-out writes. Lesson 4 computes them: with 550 connections per user, a billion posts a day becomes roughly 6.4 million timeline insertions per second.
• Ranking compute. Lesson 10 says the ranking service "might utilize specialized hardware like GPUs and TPUs" and quotes Facebook on evaluating thousands of features per person. That is the expensive tier, and it has no line in the estimate.
• Cache memory for precomputed feeds.

So 8,000 servers may well be the right order of magnitude for a real deployment — but it is right for none of the reasons given.

The transferable habit is small: when two sections of one document compute the same quantity, make them agree before you use either. A number that contradicts a number three paragraphs earlier is not an estimate; it is a template being filled in.

What the corrected numbers actually say

Put the honest figures side by side:

The pattern is consistent across the whole module: the standard estimation template measures request handling and byte counts, and in every modern system the bottleneck is somewhere else — GPU inference in that building block, location-write throughput in Uber, index maintenance in Yelp, and here fan-out amplification plus ranking compute.

When every quantity in your estimate comes back either trivial or implausible, the template is measuring the wrong thing. That is the single most useful lesson available from these four estimation sections, and it is worth more than any of the individual figures.

The estimation trap here is sizing on posts per second. Under fan-out on write the system's actual write volume is posts × average follower count, which is larger by three or four orders of magnitude — and that is the number that decides whether the model is viable.

Interview signal by level

Next: the lesson this chapter owes and gives six words to.