Requirements and Resource Estimation

In one line: scope down to upload and watch, then compute one ratio that drives every later decision.

Requirements

Functional — in scope:

• Upload. A creator uploads a video, of up to tens of gigabytes, possibly over a flaky mobile connection.
• Watch. A viewer streams it smoothly, on any device, at whatever quality their connection supports.

Functional — deliberately out of scope: search, comments, likes and dislikes, subscriptions, channel management, recommendations, moderation.

Those are real features, and this chapter covers several of them in later lessons. But in a 45-minute interview you should name them and set them aside, because they are variations on problems you would solve the same way in most systems. Upload and watch are what make this system hard.

Saying what you are not building is a signal. It shows you know the surface area and have decided where the time goes.

Non-functional:

Assumptions

Total users               : 1.5 billion
Daily active users (DAU)  : 500 million
Average video length      : 5 minutes
Raw video size (5 min)    : 600 MB   -> 120 MB per minute
Compressed size (5 min)   :  30 MB   ->   6 MB per minute
Upload rate               : 500 hours of content per minute
upload:view ratio         : 1:300

Storage

Storage per minute of video = 30 MB / 5 min = 6 MB/min

Total storage/min = hours uploaded x minutes per hour x storage per minute
                  = 500 x 60 x 6 MB
                  = 180,000 MB
                  = 180 GB per minute

That is one quality. We store about five:

5 x 6 MB = 30 MB per minute of video

500 x 60 x 30 MB = 900,000 MB = 900 GB per minute

And that still excludes raw originals. Stack the multipliers:

One quality, compressed        :  180 GB/min  =  ~95 PB/year
Five qualities                 :  900 GB/min  = ~473 PB/year
Plus raw originals (120 MB/min):  +3.6 TB/min

Raw originals dominate. At 120 MB/min against 6 MB/min compressed, keeping the raw file costs 20x what one delivery copy does.

That raises a design question worth volunteering: do you keep the raw file forever? You need it to re-transcode when a new codec arrives, but it is 20x the cost of a delivery copy and is never served to a user. An archive tier is the answer — raw originals are the canonical cold-storage workload.

Storage for thumbnails, user data, and metadata is negligible by comparison. Knowing which terms to drop is half of back-of-the-envelope work.

Bandwidth

Upload — raw video at 120 MB per minute:

500 hours/min x 60 min/hour x 120 MB/min = 3,600,000 MB/min
                                         = 60,000 MB/s
                                         = 480 Gbps

Streaming — at a 1:300 view ratio and 10 MB per minute of delivered video:

500 x 60 x 10 MB x 300 = 90,000,000 MB/min
                       = 90 TB/min
                       = 720 Tb/min
                       = 12 Tbps

The two calculations use different MB-per-minute figures, and that is the part candidates get wrong. Upload carries the raw file, because compression happens server-side after arrival. Streaming carries a compressed, transcoded stream. Using compressed size for upload understates ingress 20x; using raw size for streaming overstates egress 12x.

The general rule: size a link by the bytes actually crossing it, not by the size of the logical object. The two differ by direction whenever transformation happens in between.

Servers

Servers = requests per second / RPS per server
        = 500,000,000 / 64,000
        = 7,812.5
        ~ 8K servers

Treat that number with suspicion, and say so. It assumes 500 million DAU means 500 million requests per second, which would require every daily active user to issue a request every second.

It is a capacity-planning upper bound, not a measurement. The sanity check: 500M DAU at roughly 20 requests per day is about 115K average RPS, so 8K servers is likely an order of magnitude over-provisioned against average load.

The right way to present it: "this gives me an upper bound of 8K servers; average load is closer to 100K RPS, so realistically a few multiples of headroom over that, sized from a measured peak-to-average ratio." Quoting the pessimistic number and noting it is pessimistic is stronger than either alone.

It also assumes uniform servers, which is false — transcoding wants hardware encoders and inference wants accelerators.

Building blocks

Interview signal by level

Next: the architecture, and how an upload actually works.