Back to System design
Back-of-Envelope: Twitter Timeline Capacity
mediumThis is the estimate interviewers use to find out whether you can turn a product description into numbers that constrain a design. Done well it takes four minutes and every later decision points back to it.
ScaleDrives shard count, cache size, fanout worker count
StorageDrives total disk and replication factor
Key Concepts
1
Work in one direction: users, then actions, then bytes, then machines. Guessing a server count first
and reverse-engineering it is the common failure. Each step should follow from the last, and every
assumption should be said aloud so the interviewer can redirect you — they often will, and that is a
collaboration signal rather than a correction.
Work in one direction: users, then actions, then bytes, then machines.
2
Round aggressively and keep the units visible. 86,400 seconds becomes "about 100,000" if it helps, as
long as you say so. What matters is the magnitude and the chain of reasoning; a candidate who computes
4,630 writes per second and one who says "roughly 5,000" are equally right, and the second finishes sooner.
Round aggressively and keep the units visible.
3
The moment the estimate earns its keep is fan-out. Reads and writes look manageable until you multiply
writes by the average follower count, and suddenly the timeline-write rate is two orders of magnitude
larger than the post rate. That single multiplication is what forces the hybrid design, and it is the
reason this estimate is worth doing before drawing any boxes.
The moment the estimate earns its keep is fan-out.
4
Storage splits into two very different piles. Post bodies grow forever and are cold within days;
timeline caches are small, hot, and reconstructible. Conflating them produces answers like "we need
petabytes of RAM", which is where the estimate stops being useful.
Storage splits into two very different piles.
5
Finish with what the numbers forbid. An estimate that ends in a table has not done its job. The useful
ending is: this rules out a single database for timelines, this permits a Redis fleet for the id lists, and
this is why celebrity accounts need a different path.
Finish with what the numbers forbid.
6
What the interviewer is probing.
What the interviewer is probing.
7
1. "How would you start this estimate?" Probing: the method, not the answer. Stalls: "I
would guess." Moves up: state assumptions out loud — daily active users, tweets per user per day,
read-to-write ratio — then derive, so the interviewer can correct an input rather than the whole
answer.
1. "How would you start this estimate?"
8
2. "What is the read-to-write ratio and why does it decide the design?" Probing: the central
insight. Stalls: "They are similar." Moves up: reads outnumber writes by a large factor, which
is what makes fan-out on write worth the storage.
2. "What is the read-to-write ratio and why does it decide the design?"
9
3. "What is the fan-out problem with celebrity accounts?" Probing: the edge case. Stalls:
"None." Moves up: writing to a hundred million follower timelines per tweet is impractical, so
those are merged at read time instead — a hybrid.
3. "What is the fan-out problem with celebrity accounts?"
10
4. "What do you do if you cannot recall a figure mid-estimate?" Probing: composure. Stalls:
"Stop." Moves up: state an assumption, say it is an assumption, and carry on — the reasoning is
what is being assessed, not recall.
4. "What do you do if you cannot recall a figure mid-estimate?"
The estimate, step by step
Step 1 -- users and actions (stated assumptions)
Daily active users 200,000,000
Posts per user per day 2
Timeline opens per user per day 10
Average followers 200 Step 2 -- rates
Posts/day 200M x 2 = 400,000,000
Posts/s 400M / 86,400 = 4,630
Peak (x3) = 13,900 Timeline reads/day 200M x 10 = 2,000,000,000
Reads/s 2B / 86,400 = 23,000
Peak (x3) = 69,000 Step 3 -- the multiplication that matters
Fan-out writes/s 4,630 x 200 = 926,000
At peak 13,900 x 200 = 2,780,000
-> two orders of magnitude above the post rate. Step 4 -- bytes
Post row: id 8 B + user 8 B + text ~200 B + meta ~80 B
= ~300 B
Daily 400M x 300 B = 120 GB
Yearly = 43.8 TB
With replication (x3) = 131 TB Timeline cache: 800 ids x 8 B = 6.4 KB/user
200M users = 1.28 TB Step 5 -- what it forbids
- 926k timeline writes/s rules out a relational database for
timelines; it is a key-value fan-out problem.
- 1.28 TB of ids fits a Redis fleet; 131 TB of bodies does not,
so timelines hold ids and hydrate separately.
- A 50M-follower account cannot be fanned out synchronously:
50M writes at 100k/s per node is 500 node-seconds.Where estimates go wrong
Forgetting the multiplier
Computing posts/s and stopping. The fan-out multiplication is
the whole reason this estimate exists. Using average load for capacity
Peak is 2-5x average for consumer products, and higher for
event-driven ones (a cricket final, a product launch).
Size for peak, state the multiplier you assumed. Mixing hot and cold storage
Adding post bodies and timeline caches into one number produces
"we need 131 TB of RAM". Separate what is hot from what is
merely large. Precision theatre
4,629.6 writes per second invites a discussion about the second
decimal place. Say ~5,000 and move on. Silent assumptions
If you do not say "assuming 200 followers on average", the
interviewer cannot correct you to 500 -- and correcting you is
usually what they want to do, because it tests whether your
design survives a changed input. Never closing the loop
The estimate must end in a constraint. "So a single database
cannot take the timeline writes" is the sentence that makes the
previous four minutes worth it.