QPS and Read-vs-Write Modeling

The most decision-shaping number: the read:write ratio

The single most decision-shaping number in an estimate is the read:write ratio. It tells you which path to optimize, and optimizing the wrong path is one of the most common ways to lose a design round. A 100:1 read-heavy system (a social feed, a product catalog) wants caches, read replicas, and denormalized read models. A write-heavy or balanced system (an analytics ingest pipeline, a metrics store) wants write batching, append-only logs, and horizontally sharded write paths.

Start by converting DAU to QPS with explicit arithmetic, exactly as in Fermi estimation. Then compute reads and writes separately and take the ratio.

Fan-out: where one write becomes many

The subtlety in feed-like systems is fan-out: one write can generate many logical reads, or one read can require merging many sources. This is the fan-out-on-write versus fan-out-on-read decision.

Table

The two failure modes are mirror images, which is why production feeds do both: push for ordinary accounts, pull for the handful of celebrities, and merge the two at read time.

Dimension	Fan-out on write (precompute)	Fan-out on read (merge at query time)
What happens	user posts → push into every follower's feed cache	user opens feed → pull recent posts from each followee → merge and sort
Read cost	cheap: one cache GET	expensive: N fetches plus a merge
Write cost	expensive: N inserts	cheap: one append
Good when	reads far outnumber writes	a few accounts have enormous fan-out
Breaks on	a celebrity with 10M followers: one post becomes 10M inserts	a user following thousands of accounts: one read becomes thousands of fetches

Worked example: a feed with 50M DAU, each user reads their feed 20 times/day and posts 0.5 times/day, average 200 followers.

reads/day  = 50M x 20  = 10^9       -> avg  ~10k QPS,  peak ~30k QPS
writes/day = 50M x 0.5 = 2.5 x 10^7 -> avg ~250 QPS,  peak ~750 QPS
read:write ratio ~= 40:1  (read-heavy)

But if you fan out on write, each post writes into ~200 follower feeds. Effective feed-insert QPS = 250 x 200 = 50k QPS of cache writes. So the naive write QPS (250) understates the real write cost by the fan-out factor. This is why the ratio alone is not enough; you must model where the fan-out happens.

Interview nuance: the strong answer usually picks a hybrid. Fan out on write for normal users (cheap reads), but for celebrities with millions of followers, fan out on read (pull their posts at query time) so a single tweet does not trigger tens of millions of feed inserts. Naming this hybrid is a senior signal.

Averages lie: design for the hot key

Access is Zipfian: a small number of hot keys (viral posts, celebrity accounts, trending products) take a hugely disproportionate share of traffic. Your design must survive the hot key, not just the average. A hot key can saturate a single cache node or shard even when the fleet-wide average looks fine, so you plan for replication of hot keys or request coalescing.

Finally, translate QPS into a first-order server count. If a tuned application server handles ~10k QPS, then 30k peak read QPS needs at least 3 to 4 app servers behind the load balancer plus headroom, and a cache handling 100k+ ops/sec covers the feed reads.

Recap: derive read and write QPS separately, take the ratio to decide read-optimized versus write-optimized, model where fan-out happens (write vs read, and a celebrity hybrid), and design for the hot key rather than the average.