Requirements and Resource Estimation
In one line: four of the five functional requirements are ordinary CRUD, ranking is not, and the storage plan is really a plan about video.
Requirements
Functional:
| Requirement | Detail |
|---|---|
| Questions and answers | Post questions and answers containing text, images, and videos |
| Interactions | Upvote, downvote, and comment on answers |
| Search | Find existing questions on the platform |
| Feed and recommendation | A personalized feed based on user interests, to drive discovery |
| Ranking | Answers ordered by usefulness, best content first |
Non-functional:
| Requirement | Detail |
|---|---|
| Scalability | Absorb user and feature growth without degrading |
| Consistency | Content consistent across views; new posts and comments may propagate with a slight delay |
| Availability | Stay up under high concurrent load |
| Performance | Low latency, especially on reads |
Four of the five functional requirements are ordinary CRUD. Ranking is not.
"Best content first" is a judgment the system has to make, and the simple proxies fail predictably. Sorting by date rewards whoever answered first. Sorting by upvotes rewards whatever is cheapest to appreciate — a witty one-liner beats a careful expert answer, because appreciating the one-liner costs nothing.
So ranking needs an actual model, which is why the architecture carries an ML engine and a store underneath it holding extracted features. Retrieval is the easy half; ranking is where the system lives.
Assumptions
Total users : 1 billion (300 million DAU) Questions with images : 15% (250 KB each) Questions with videos : 5% (5 MB each) Activity per DAU : 1 question/day, receiving 2 answers, 10 upvotes, 5 comments Text per question : 100 KB collectively (question + answers + comments) Questions viewed : 20 per user per day
Storage
Total questions/day = 300 million
Text : 300M x 100 KB = 30 TB
Image : 300M x 15% x 250 KB = 11.25 TB
Video : 300M x 5% x 5 MB = 75 TB
--------
Total ~ 116.25 TB/day
= 42.43 PB/year
This is the number worth extracting from the whole lesson. One question in twenty has a video, and video consumes nearly two-thirds of daily storage. Text — present in every single question — is barely a quarter.
Three consequences follow, and each justifies a decision later in the chapter.
Media belongs in blob storage, not the database. Otherwise the database is dominated by data it cannot query, index, or usefully replicate.
Optimizing text storage is pointless. Compressing 30 TB of text by 30% saves 9 TB; a modest video-encoding improvement saves multiples of that. Optimize where the bytes are.
A change in video policy dominates the capacity plan. If adoption doubles from 5% to 10%, storage goes from 116 TB/day to 191 TB/day — a 64% increase from a five-percentage-point product decision.
The general lesson, which recurs in every media-carrying system: a small fraction of large objects dominates the cost, so the capacity plan is really a plan about that fraction.
Bandwidth
Incoming — everything written must arrive:
116.25 TB / 86,400 s x 8 = ~11 Gbps
Outgoing — 300 million users viewing 20 questions each:
Views/second = 300M x 20 / 86,400 = 69,444
Text : 69,444 x 100 KB x 8 = 55.56 Gbps
Image : 69,444 x 15% x 250 KB x 8 = 20.83 Gbps
Video : 69,444 x 5% x 5 MB x 8 = 138.89 Gbps
------------
Outgoing ~ 215.3 Gbps
Total = 11 + 215.3 = 226.3 Gbps
Egress is about 20x ingress, which is the read-heavy shape from Lesson 1 in numbers. And note the composition repeats: video is the majority of outgoing bandwidth too, at 139 of 215 Gbps.
That points the same way as storage. A CDN for media is not an optimization here; it is where most of the bytes are.
The composition repeats on the wire. Video is 139 of 215 Gbps outgoing, which points the same way as storage: a CDN for media is not an optimization here, it is where most of the bytes are.
Servers
Servers = 300,000,000 / 64,000 = 4,687.5 ~ 4.7K servers
Quote this and then undercut it. It treats 300 million DAU as 300 million requests per second, which would require every daily active user to issue a request every second.
Cross-check against the bandwidth model in this same lesson: 20 views per user per day gives 69,444 views per second — four orders of magnitude below 300 million.
Both are arithmetically correct from their inputs, and they describe different systems. The bandwidth model is the credible one; the server figure is a deliberately pessimistic capacity ceiling. Saying so is stronger than quoting either alone: "4.7K is an upper bound from a worst-case peak assumption; the traffic model in the same lesson implies far less, and I'd size from a measured peak-to-average ratio."
Building blocks
| Building block | Used for |
|---|---|
| Relational store | Questions, answers, comments, votes — the critical consistent data |
| Wide-column store | View counts, ranking scores, extracted ML features, the search index |
| Blob storage | Images and video — 65% of the bytes |
| Distributed caches | Read results, and counters that need atomic increment |
| Message queue | Durable background work, once the in-memory queues are replaced |
| Compute hosts | ML inference and feature extraction |
Key takeaway
Ranking is the one requirement that is not CRUD, and the cheap proxies fail — upvotes reward what is cheapest to appreciate, so it needs a model. 5% of questions carry video and that is 65% of storage and 65% of egress, so media goes to blob storage and text optimization is beside the point. Annual storage carries two multipliers — replication, and the 700M inactive users whose content must still be served. The 4.7K server figure is a pessimistic ceiling; the traffic model in the same lesson implies four orders of magnitude less.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "Multiply users by content size to get storage, and something similar for bandwidth." |
| L5 | Breaks storage down by type: "video is only 5% of questions but most of the storage, so media goes to blob storage and gets a CDN." |
| Staff+ | Draws the design consequences and qualifies the numbers: "5% of questions carry video and that's two-thirds of both storage and egress — so the capacity plan is really a plan about video, and a product change from 5% to 10% adoption raises storage 64%. I'd also flag that annual storage needs times-three for replication and covers only active users, when the 700 million inactive ones still have content to serve. And the 4.7K server figure treats DAU as peak RPS — the bandwidth model in the same breath implies 69K views a second, so I'd call it a ceiling, not an estimate." |
Next: the baseline architecture.