Scaling reads and writes

Most designs hit one of two limits first. Reads exceed what one primary can serve. Or writes exceed what one machine can absorb. The fixes are different, so name the limit before you pick a tool. The rest of the deep-dive patterns build on these basics.

The big idea

Think of a library. If many people want to read one book, make more copies. If many people want to write books, you need more authors working on different shelves. Copies are cheap to read but can be out of date. Splitting the writing is harder, because the shelves must be divided up first.

Walking through it

Say one primary serves 5,000 reads per second, and the product page needs 50,000. These numbers are an example, not a measurement. Ignoring lag, you need 10 replicas that each serve 5,000 reads per second. Replicas cannot take writes, so they do not help the write side.

Tools for reads

• Read replicas. Serve queries that can tolerate lag. Trade: reads may be stale.
• Caches. Keep hot values in memory with a time-to-live. Trade: invalidation is hard.
• CDNs. Serve public, rarely changing files from the edge. Trade: updates take time to spread.
• Denormalized views. Precompute what a page needs. Trade: writes must update the copies.

Tools for writes

• Sharding. Split data by a key with many values, so writes spread out. Trade: queries across shards get harder.
• Queues. Absorb spikes and let workers process at their own pace. Trade: results arrive later.
• Write-optimized stores. Log-structured engines turn writes into sequential appends. Trade: reads can cost more.

Before choosing, ask one question: how stale can a value be? View counts tolerate seconds. A seat count or a balance does not.

Common mistakes

• Adding replicas to fix write load. Every write still goes to the primary.
• Caching without an invalidation plan. Stale data stays until the time-to-live expires.
• Sharding by a key with few values. Most of the data ends up on a few shards.

Check yourself

1. Why don't read replicas help a write-heavy workload? Replicas cannot accept writes. All writes still go to the primary.
2. Which staleness is fine for view counts, and which for seat purchases? Seconds of staleness is fine for view counts. Seat purchases need a strong, current answer.

Key takeaways

• Name the limit first: reads, writes, or both.
• Read scaling uses copies, caches and CDNs, and accepts some staleness.
• Write scaling uses sharding, queues and suitable stores.
• Ask how stale each value may be before choosing.

Further learning

Next, see how one popular key breaks these tools, in hot keys.

For the details of each tool, see caching, sharding and replication.