Read-Heavy vs Write-Heavy Systems

How the ratio of reads to writes shapes a design: every choice moves work between the write path and the read path, and the ratio tells you which way to move it.

Overview

A read-heavy system answers far more reads than it accepts writes: a product catalog, a news site, a social graph. A write-heavy system takes in far more data than it serves back: metrics, logs, sensor readings, clickstreams. Most real systems mix both, part by part.

The ratio matters because almost every design choice moves work from one path to the other. An index, a cache or a precomputed feed makes reads cheaper by making each write do more. Writing raw events to a log and computing answers later makes writes cheap and reads expensive. There is no free option, only a choice about which side pays.

For a sense of how lopsided real workloads get: Facebook's 2013 paper on TAO, its social-graph store, reported that only 0.2% of requests involved a write, with the system handling a billion reads and millions of writes per second. The Dynamo paper describes the other end of the same dial: some services ran Dynamo as a high-performance read engine with R = 1 and W = N, while the store's default purpose was to stay always writable.

What you will be able to do

  • Measure a workload's read and write rates, including the hidden cost of one write.
  • Explain the read, update and memory trade-off and apply it to caches, indexes and precomputed views.
  • Choose between fan-out on write and fan-out on read with a quick calculation.
  • Tune replication and quorums toward reads or writes, and pick a storage engine that fits.
  • Handle read hot spots and write hot spots, which need different fixes.

Key concepts

  • Read-to-write ratio
  • Work on read vs work on write
  • Read, update and memory costs
  • Fan-out on write vs on read
  • Quorum tuning (R and W)
  • B-tree vs LSM tree
  • Replication lag
  • Hot keys

Interview questions

  • Why does the read-to-write ratio matter so much in system design?
  • How would you design for a read-heavy workload?
  • How would you design for a write-heavy workload?
  • Fan-out on write or fan-out on read for a news feed?
  • How can you tune replication for reads or for writes?
  • How do B-tree and LSM storage engines differ for reads and writes?
  • A key is hot. How does the fix differ for reads and for writes?

Sign up free to read the full topic

More System Design topics

Start free on Cariara · Coding problems · System design studio