Resource Estimation

In one line: this lesson does something no previous chapter did — it computes a uniform-distribution figure and frames it as a lower bound. That instinct is right. Then it produces two more answers that disagree with it and with each other.

Assumptions

• Total users: 1 billion (500 million daily active)
• Daily uploads: 60 million photos and 35 million videos
• File sizes: max 3 MB per photo, 150 MB per video
• Traffic: average 20 requests per user per day

Storage

Photos:  60,000,000 x 3 MB   =   180 TB/day
Videos:  35,000,000 x 150 MB = 5,250 TB/day
                               -------------
Total                        = 5,430 TB/day
Annual: 5,430 x 365          = 1,981,950 TB = 1,981.95 PB

All figures reproduce exactly.

One assumption produces 96.7% of the answer — and it is a maximum used as an average

Look at the split:

Videos:  5,250 TB of 5,430 TB  =  96.7%
Photos:    180 TB              =   3.3%

Video is essentially the entire estimate. And the number driving it is described in the assumptions as "max 150 MB per video" — a maximum, substituted directly as if it were the average.

That is a meaningful difference. Most uploads are nowhere near the cap; short clips at typical mobile bitrates run to a few megabytes. Recompute with plausible averages:

So the annual storage figure could plausibly be a tenth of what is published, and nothing else in the estimate would change.

Two habits worth taking from this.

Never substitute a maximum for a mean. A cap tells you the worst case for one item; a storage estimate needs the expected value across all of them. In a long-tailed distribution — and file sizes are long-tailed — those differ by an order of magnitude.

Find the dominant term and interrogate it first. When one line is 96.7% of the total, the accuracy of every other line is irrelevant. You could be wrong about photos by a factor of ten and move the answer by 3%.

The published figure is not useless — as an upper bound on a storage tier it is defensible. But it should be labelled as one, exactly as the chapter labels its server bounds.

Bandwidth

Incoming = 5,430 TB / 86,400 s = 62.84 GB/s = 502.8 Gb/s
Outgoing = 100 x incoming      = 50.28 Tb/s      (read:write ratio of 100:1)

50 Tb/s is the largest egress figure in the course, and it explains the whole architecture

Put it beside the others:

Even granting that the 150 MB assumption inflates it, this is four times YouTube's figure and two orders of magnitude above the text-centric systems.

That number is why the finalized design in Lesson 11 puts the CDN in front of the application servers rather than beside them. At 50 Tb/s, serving media from origin is not a latency optimization problem — it is arithmetically impossible. No practical origin fleet has that egress.

It also explains the design's own remark: "Media compression can reduce file sizes before delivery. Content is cached near users through CDNs and edge caches located at IXPs and ISP networks." Pushing caches into ISP networks is what you do when your egress exceeds what you can buy transit for.

When egress reaches tens of terabits per second, the CDN stops being a component and becomes the serving architecture.

Server count — three answers

The chapter computes this twice explicitly and a third time in its interactive table.

The table and the prose disagree about server capacity by 8x

The interactive table lists "Number of requests a server can handle per day = 691,200,000."

691,200,000 / 86,400 = 8,000 RPS per server

But the prose uses 64,000 RPS in both of its calculations. Same lesson, same system, 8× apart on the most basic input.

That is why the table's answer of 15 servers does not match either prose figure:

500M users x 20 requests = 10 billion requests/day
10,000,000,000 / 691,200,000 = 14.5 ~= 15 servers

The arithmetic is internally correct in each case; the capacity assumption differs. Neither is flagged, so a reader cannot tell which to carry forward.

When a document states a per-unit capacity in two places, check they match before using either result. This is the same class of error as the newsfeed chapter's traffic-versus-server contradiction, in a different variable.

The 'peak load' figure is not a peak — and the chapter's own note says how to fix it

Credit first: framing the estimate as lower and upper bounds is genuinely good practice, and no other chapter in this module does it. The design says so explicitly: "These scenarios establish the lower and upper bounds for required server capacity."

The problem is the upper bound. It assumes "Daily Active Users as a proxy for peak concurrent requests" — 500 million requests per second.

Computed average:  115,741 RPS
"Peak" assumption: 500,000,000 RPS
Ratio:             4,320x

No real system peaks at 4,320× its average. Diurnal traffic peaks are typically 2–5× the mean; a viral event might reach 10×. Four thousand times is not a peak, it is the DAU count wearing a different label.

And the chapter tells you the right method two sentences later: "These bounds can be refined by adjusting traffic assumptions, for example, assuming 20% of daily requests occur during peak concurrency."

Apply it:

20% of 10B daily requests = 2 billion, concentrated in 1 hour
2,000,000,000 / 3,600 = 555,556 RPS
555,556 / 64,000 = ~9 servers

About 9 servers, which is a defensible upper bound — roughly 5× the uniform figure, exactly the shape a real diurnal peak has.

So the honest range is 2 to 9 servers for request handling, not 2 to 8,000. And the deeper point is the same one every chapter in this module has reached: request handling is not what sizes these systems. What does, here, is the media tier — 5,430 TB a day of ingest and 50 Tb/s of egress, neither of which is served by a 64,000-RPS application server.

What actually sizes this system

Collecting the honest figures:

The two omissions matter. Transcoding — converting each upload into multiple resolutions and bitrates — is a large compute cost in any video platform, and that building block treated it as a first-class subsystem. Here, 35 million videos a day pass through it and it has no line in the estimate.

Fan-out is covered thoroughly in Lessons 8 and 9 but never quantified. With 500 million daily active users and a follower graph that reaches 400 million on one account, it is the other tier that would dominate a real capacity plan.

An estimate that only sizes the tier your template knows about will always come back small.

The two numbers differ by three orders of magnitude, and that gap is the storage plan. Metadata is small enough to keep hot forever; media is where cost lives, so the answer is tiering by access recency — a post from four years ago can sit in archival storage at a fraction of the price.

Interview signal by level

Next: the high-level design.