The Numbers, Recalled

In one line: you cannot evaluate an architecture you cannot size. This chapter declines to estimate, so we recall the figures from the Foundations module and — more usefully — say what each one forces.

A note on this lesson

The design states: "We previously used Twitter as a case study in the back-of-the-envelope chapter. We will not repeat the resource estimation exercise here; instead, we will focus directly on the system components."

That is a fair deferral, though it contradicts the chapter's own roadmap, which promises the requirements lesson "also estimates storage, bandwidth, and computational resource needs."

The figures below come from the Back-of-the-Envelope Calculations chapter in Foundations, where they were derived in full. What is authored here is the mapping from each number to the architectural decision it drives, because that is what makes an estimate worth carrying into a design.

The figures

Daily active users        = 500M
Tweets per user per day   = 3            ->  1.5 BILLION tweets/day
Tweets with images        = 10%   @ 200 KB
Tweets with video         = 5%    @ 3 MB
Tweet text and metadata   = 250 bytes
Tweets viewed per user    = 50           ->  289K views/second

What each number forces

Video is 88% of storage and 88% of egress — from 5% of tweets

The single most important thing in the estimate:

Storage:  video 225 TB of 255 TB total   = 88%
Egress:   video 347 Gbps of 394 Gbps     = 88%
Text:     0.375 TB of 255 TB             = 0.15%

Five percent of tweets consume ninety percent of the infrastructure, and the thing Twitter is actually about — 280 characters of text — is a rounding error.

That splits the system in two, and the split explains the architecture:

So Lesson 6's blob store is not an incidental component — it carries essentially the whole storage cost. And the CDN exists to keep 347 Gbps of video off the application tier.

Meanwhile the text path, at 0.375 TB per day, is small enough to hold almost entirely in memory across a cluster — which is exactly what makes Lesson 8's caching strategy and Lesson 7's RAM-resident search index viable.

When one content type dominates the bytes, you have two systems: a metadata system constrained by query rate and a delivery system constrained by bandwidth. Same conclusion the YouTube and Google Maps chapters reached, arriving here from a different direction.

17,361 writes per second is small — and it is not the number that matters

Posting tweets generates about 17,000 writes per second. Against the 64,000 RPS a single server handles, that is a fraction of one machine.

So why does Twitter run thousands of servers?

Because a tweet is not one write. Lesson 2 established that the 1:1000 ratio is best read as fan-out amplification, and this is where it bites:

1 tweet posted
  -> written to the tweet store                     1 write
  -> inserted into N followers' timelines           N writes
  -> indexed for search                             1 write
  -> published to the analytics pipeline            1 write
  -> media written to blob store                    1 write

With an average of a few hundred followers, one user action becomes hundreds of internal operations. That is what turns 17,000 user writes per second into millions of internal ones, and it is the reason Lesson 5's fan-out design matters more than any raw rate in this table.

The user-facing write rate tells you almost nothing about a fan-out system's load. What matters is the amplification factor, and it is set by the follower distribution.

289K reads per second is what makes caching mandatory rather than optional

289,000 tweet views per second, each needing tweet text, author details, and engagement counts.

Served from a database, that is hundreds of thousands of point lookups per second — achievable, expensively. Served from cache, it is memory access.

Two properties make caching unusually effective here:

The working set is small. Recent tweets are the overwhelming majority of reads, and Lesson 3's arithmetic says a day of tweet text is 0.375 TB. A week is 2.6 TB. That fits comfortably in a cluster's RAM.

Popularity is extremely skewed. A tweet from a large account is read millions of times; most tweets are read a handful of times. Skew is the condition under which caching pays.

This is why Lesson 8 spends its time on cache metadata overhead rather than on hit rates. When you are caching hundreds of millions of ~250-byte objects, the per-object bookkeeping is a material fraction of your memory bill — a problem that only exists because the objects are so small and so numerous.

Two more figures the chapter mentions in passing

Both are worth converting into something meaningful.

300 PB in HDFS. That is roughly three years of production data at 93 PB/year, and it is logs, backups, and analytics rather than serving data. The offline footprint dwarfs the online one — a common and under-appreciated property of large systems.

400 billion events per day.

400,000,000,000 / 86,400 = 4.63 MILLION events per second

That is 267 times the tweet-posting rate, and it is the real reason Kafka is in the architecture. Every like, view, click, impression, and scroll is an event. The analytics pipeline processes two orders of magnitude more traffic than the product's core write path.

Instrumentation usually generates more data than the thing being instrumented. Worth internalizing, because it is the number people forget when sizing a system.

Next: the API.