“It scales” isn’t yes or no. It’s three numbers.
Name the load, the percentile you hold and the cost per request: “p99 under 200 ms at 20,000 requests a second”.
300k/s
timeline inserts, from ≈ 5,000 tweets a second
Twitter, 2012. Writes were modest; fan-out wasn’t. One tweet to 31 million followers needed ≈ 100 seconds of that capacity.
Three ways to split the work: clone, by function, by data.
X copies everything. Y divides the code. Z divides the data. Only Y and Z shrink what one machine must hold.
Writes maxed out. Now what?
Bad: More replicas
Every replica applies every write. Ten replicas: ten times the work, no extra throughput.
Good: Divide ownership
Shard so each key has one home. Queue bursts; batch small writes.
Say 5% of the work passes one step at a time through a single primary. You add 32 workers.
Amdahl’s law
You get 12.5×. However many you add, the ceiling is 1 ÷ 0.05 = 20×.
Add a little cross-talk, and more nodes can mean less throughput.
Nodes must keep copies in sync, a cost that grows with N². Here throughput peaks near 22 nodes, then falls.
Most requests should touch one partition
- Split a hot row into blocks owned by partitions
- Run many small consensus groups, one per shard
- Group related tables under one shard key
Remember
Scaling means proportional capacity at the same p99 and cost per request. Name the load, clone stateless tiers, copy reads, divide writes, and keep coordination off the hot path.