Resource Estimation

In one line: the four numbers here are worth doing live in an interview, and one of them — the 400x gap between ingress and egress — is the single most design-relevant fact in the chapter.

Assumptions

Daily active users (DAU)        : 5 million
Requests per second per server  : 500
Average video size              : 50 MB
Average thumbnail size          : 20 KB
Daily video uploads             : 250,000
Daily read requests per user    : 20

Number of servers

Using DAU as a proxy for peak RPS, we estimate 5 million requests per second:

Servers needed at peak = requests per second / RPS per server
                       = 5,000,000 / 500
                       = 10,000 servers

Note: we estimate 500 RPS per server (down from 64,000 RPS) to account for the I/O-intensive nature of blob operations.

The 500 versus 64,000 adjustment is the most instructive line in this lesson

The course's standard server figure is 64,000 RPS. Here it is cut by a factor of 128, and the justification is one phrase: blob operations are I/O-intensive.

That is the right instinct and worth generalizing. A generic RPS number assumes requests are CPU-bound and small — parse, look up, serialize, respond. A blob request moves tens of megabytes off a disk and onto a network. The bottleneck is not the CPU at all; it is disk throughput and NIC saturation.

Sanity-check it: at 500 requests/second each moving 50 MB, that server is pushing 25 GB/s — already far beyond a single machine. So even 500 is generous for full-video requests, and the real fleet is sized by bandwidth, not request count.

The transferable lesson: a standard RPS constant is only valid for the workload it was measured on. Adjusting it, and saying why, is exactly the judgment that building block was teaching.

Storage

Total storage/day = videos per day x (storage per video + storage per thumbnail)
                  = 250,000 x (50 MB + 20 KB)
                  = 250,000 x 50.02 MB
                  = 12,505,000 MB
                  ~ 12.51 TB/day

Read the qualifier — this is one copy, in one resolution

The source states it precisely: 12.51 TB/day of daily storage for a single copy of uploaded videos in one resolution.

That is the floor, not the answer. Apply Lesson 1's two multipliers:

One copy, one resolution                  :  12.51 TB/day
x transcoding fan-out (say 3x)            :  ~37.5 TB/day
x replication factor (Lesson 10: 3 copies):  ~112 TB/day

So the storage the system actually provisions is close to an order of magnitude above the headline figure. Quoting 12.51 TB/day as the capacity requirement would under-provision by 9x.

The thumbnail is also worth a glance: at 20 KB against 50 MB it is 0.04% of the video, contributing 5 GB of the 12,505 GB. It is correct to include it and correct to notice it does not matter — knowing which terms to drop is half of back-of-the-envelope work.

Bandwidth

Incoming traffic — determined by daily upload volume:

Total bandwidth = total storage per day / seconds in a day
                = 12.51 TB / 86,400 s
                ~ 1.16 Gb/s

Outgoing traffic — blob stores are read-intensive:

Total bandwidth = (active users/day x requests/user/day x data size) / seconds in a day
                = (5,000,000 x 20 x 50 MB) / 86,400
                = 5,000,000,000 MB / 86,400
                ~ 462.96 Gb/s

Egress is 400x ingress — and that single ratio decides the architecture

462.96 / 1.16 ~ 400x

This is the number to carry out of the lesson. It is not a detail; it dictates most of the design.

Optimize the read path, essentially ignore the write path. Uploads at 1.16 Gb/s fit comfortably on a couple of machines. Reads at 463 Gb/s need a fleet.

This is why a CDN is mandatory, not optional. Serving 463 Gb/s from origin is enormously expensive and slow for distant users. Push popular blobs to the edge and origin egress collapses — which is exactly why Lesson 11's caching section ends with CDN for public blobs.

It is why clients read chunks directly from data nodes (Lesson 7) rather than through the frontend. Proxying 463 Gb/s through a frontend tier would require that tier to carry the full egress twice — in and out.

And it is why cloud providers bill egress heavily. Bandwidth out is the scarce resource; storage and ingress are comparatively cheap. That pricing shape is a direct reflection of this ratio.

If you compute one number in a blob store interview, compute this ratio and then say what it implies. The implications are the answer.

A quick sanity check on the read assumption

"20 read requests per user per day, each 50 MB" means every user pulls 1 GB per day. For a video platform that is plausible — roughly 20 video views.

But note it assumes every read is a full video at full size, which overstates reality: many reads are thumbnails, many videos are watched at lower resolutions, and many are abandoned partway. A more careful model would split reads by type.

Doing the simple version first and naming what it overstates is the right interview move. It gives a defensible upper bound quickly, and it shows you know where the model is soft rather than presenting an estimate as though it were a measurement.

Interview signal by level

Next: the architecture and its API.