Signals that you’re scaling reads
- Reads outnumber writes 100 to 1,000 times
- Many people read the same thing
- A strict read latency target, like p99 under 200 ms
- Predictable hot items: a flash sale at 12:00
Climb the ladder. Stop at the first rung that fits.
Fix the queries, then replicas, a cache, the CDN, precomputed views, and finally sharding with hot-key tricks. Each rung buys throughput and costs staleness.
100,000 views a second. More replicas?
Bad: 20+ replicas
Full-price copies re-answering the same pages. Aurora caps a cluster at 15.
Good: Cache the hot set
The catalogue, about 4 GB, fits in memory. Replicas take misses.
5×
less database load from 95% to 99% hits
Database reads = reads × (1 − hit rate). At 100,000 reads a second, 95% hits leave 5,000 misses; 99% leaves 1,000.
Asha saves a new address. The reload hits a lagging replica and shows the old one.
The fix
Pin her reads to the primary for 5 s, or use only replicas past her write’s log position.
One hot key can melt one shard
Sharding spreads keys, not the traffic on one key. 100,000 reads a second on p:42 land on the shard that owns it. Eight copies spread the load.
Every layer serves something older. Say how old.
Stack the rungs and only about 2% of page views reach a database. State the staleness per layer, not a vague “eventually consistent”.
Say it like this
Make each read cheap, then keep most reads off the primary, rung by rung. Stop at the first rung that meets your numbers, and state each layer’s staleness.