Scaling reads

A ladder of techniques for a read-heavy system, in the order you should actually propose them.

2 min read system-design

Most product systems are read-heavy. The mistake is to shard immediately. Sharding is a write and data-size tool that makes reads more complicated. Climb this ladder and stop when the numbers work.

1. Make one read cheap

An index that matches the filter and the sort turns a scan into a handful of page fetches. A covering index avoids the table. This is not glamorous and it is often the whole interview. Check the plan before you draw a new datastore.

2. Cache the hot set

Cache-aside in Redis for objects many users read: a video’s metadata, a short-link redirect, a public profile. TTL plus delete-on-write. Single-flight on miss so expiry is not a stampede. If the object is public and large, prefer the CDN and skip the application cache.

Do not cache per-user responses unless the hit rate is real. Cache the shared parts and assemble the page.

3. Replicas

Point cache misses at a replica. Keep the primary for writes and for the read that must see the write. Graph replica lag. A replica that is minutes behind is a second primary you have forgotten to feed.

4. Edge

Anything with a stable URL and the same bytes for everyone goes to the CDN. Version the URL so a publish is a new key, not a purge of every city. A public video segment and a versioned thumbnail belong here. A logged-in feed does not. If one object is hot enough to miss on every edge at once, put an origin shield in front of the app so those misses collapse. The CDN page is the list of responses that must stay uncached.

5. Only then, split

If the working set does not fit one machine, or a single key’s reads melt one cache node, replicate that key or partition the dataset. Scatter-gather reads need a deadline and a policy for a shard that is down (fail the request, or return a partial result and say so).

At every step, state the staleness. “This cache can be 30 seconds old” is a design. “I added a cache” is a hope.

flowchart LR
  U[User] --> CDN
  CDN -->|miss| API
  API --> Redis
  Redis -->|miss| Replica
  API -->|write and read-your-writes| Primary
  Primary --> Replica

Check yourself

Answer the questions. Multiple choice is scored on this device only.

1. The hot query is a sequential scan. The first fix is:

2. Read replicas do not help when:

3. Give the ladder in order.