Requirements and Resource Estimation

In one line: the estimation here contains a genuine internal contradiction, and working out which half is wrong teaches more about back-of-the-envelope reasoning than a clean calculation would.

Requirements

Functional:

• Search: users should receive relevant content matching their search queries.

Non-functional:

'Regardless of the data volume' is the requirement doing real work

Most latency requirements say "fast." This one says fast even as the corpus grows, which is a far stronger claim.

A naive system's search time grows linearly with document count — the design's own analogy: "searching a shelf of one million books takes significantly longer than searching a shelf of one hundred."

Meeting "regardless of volume" means breaking that relationship, and there are only two mechanisms:

• Indexing makes lookup roughly independent of corpus size — a hash lookup on a term costs the same whether there are a thousand documents or a billion.
• Partitioning keeps each machine's slice constant as the corpus grows, so you add machines rather than adding work per machine.

Every architectural decision in this chapter serves one of those two. Reading the requirement this way makes the rest of the design feel derived rather than assembled.

Cost efficiency is why this design uses commodity hardware

Listing cost as a non-functional requirement is less common than it should be, and it has a direct architectural consequence stated later: "distributed systems allow the use of cost-effective commodity hardware rather than expensive mainframes."

Given the choice between one very large machine and many small ones, the requirement picks many small ones — which then forces partitioning, replication, and failure handling, because commodity nodes fail.

So "cost efficiency" is not a footnote; it is what makes this a distributed systems problem at all. A single sufficiently large machine would be simpler, and the requirement rules it out.

Resource estimation

Using YouTube search as the baseline.

Servers

We assume 150 million daily active users (DAU) and use the heuristic of DAU as a proxy for requests per second, setting the design target at 150 million RPS. At 64,000 RPS per server:

Servers = requests per second / RPS per server
        = 150,000,000 / 64,000
        = 2,343.75
        ~ 2,350 servers

Note: concurrent requests (RPS) dictate server requirements more significantly than total daily volume.

Storage

Metadata is stored as JSON documents keyed by Video ID — title, description, channel, transcript.

Assumptions
  JSON document size : 200 KB
  Unique terms       : 1,000 keys per document
  Index entry size   : 100 bytes per term

Storage per video = storage per doc + (terms per doc x storage per term)
                  = 200 KB + (1,000 x 100 B)
                  = 200 KB + 100 KB
                  = 300 KB

Storage per day   = 6,000 videos x 300 KB
                  = 1,800,000 KB
                  = 1.8 GB/day

Indexing 6,000 videos per day requires 1.8 GB of storage. This estimate is specific to YouTube's upload rate; a multi-tenant service would require significantly more.

Bandwidth

Requests per second = 150,000,000 / 86,400 = 1,736.11

Incoming: 1,736.11 x 100 B    ~  1.39 Mb/s   (query size 100 bytes)
Outgoing: 1,736.11 x 4,000 B  ~ 55.56 Mb/s   (80 suggestions x 50 bytes)
                                --------
Total                          ~ 56.95 Mb/s

Note: these estimates assume text-only results. While many services include thumbnails, keeping the payload small ensures near real-time performance.

The two halves of this estimation contradict each other — and spotting that is the lesson

Look carefully at the request rate used in each part:

Server estimate    : 150,000,000 requests per SECOND
Bandwidth estimate :       1,736 requests per second   (150M per DAY / 86,400)

Those differ by a factor of about 86,000. Both calculations are arithmetically correct from their own inputs, but they cannot both describe the same system.

Which is right? The bandwidth model. 150 million DAU each issuing one search per day is ~1,736 average RPS; even at a 10x peak-to-average ratio that is under 20,000 RPS — comfortably served by a handful of servers, not 2,350. Meanwhile 150 million RPS would generate not 57 Mb/s but roughly 5 Tb/s of egress.

The error is applying "DAU as a proxy for peak RPS" literally. That heuristic means "assume peak RPS is on the order of your DAU count" as a deliberately pessimistic upper bound for capacity planning — not that every daily active user issues a request every second.

Two things to take from this. First, cross-check your estimates against each other: if two derived numbers imply wildly different systems, one input is wrong. Second, a heuristic is not a formula — that building block's point was to build intuition, and intuition includes noticing when a result is absurd. In an interview, catching your own inconsistency is a strong signal, not a weak one.

The storage number is remarkably small — and that is the real finding

1.8 GB/day is tiny. A single laptop absorbs a year of it.

Compare object storage: storing YouTube's videos was 12.5 TB/day, and provisioned nearer 112 TB/day. Storing the searchable text about those videos is roughly 7,000x smaller.

That asymmetry is worth internalizing, because it tells you where the engineering difficulty actually is. Search is not a storage problem — the index is small enough to be unremarkable. Search is a latency and query-throughput problem.

Note the index overhead too: 100 KB of index for 200 KB of document, so the index is 50% on top of the raw data. That is the "storage overhead" disadvantage Lesson 3 lists for inverted indexes, quantified — a real cost, and clearly worth paying.

And take the caveat seriously: this is one tenant at 6,000 uploads/day. Web-scale search over hundreds of billions of pages is a different regime entirely, which is exactly why Lesson 5 says a single machine cannot hold the index in memory.

The constraint people miss: adding shards to hold more data also adds work to every query, because document partitioning means each search fans out to all of them. Shard count is therefore capped by query cost rather than by storage.

Building blocks

We require a distributed storage system for the raw data and the index. The design uses a blob store for this purpose.

The blob store choice is a good fit, and it's worth saying why

Index files are large, immutable, write-once-read-many binaries — exactly the profile object storage was built for.

An indexer produces a binary index file and never modifies it; a new index is a new file. Searchers read it repeatedly. That is WORM access, so all of the blob store's properties apply: flat namespace, no locking, cheap replication, no cache-invalidation problem.

It is also what makes Lesson 11's architecture possible. Indexers upload finished index files and searchers download them, with distributed storage as the handoff point — no direct coupling between the two clusters at all.

Interview signal by level

Next: the structure that makes fast lookup possible.