Scaling Reads: Indexes, Replicas, Caches, CDNs and Precomputed Views

The signals

The signal is a lopsided read to write ratio. Words like view, browse, load the page, show the profile. A URL shortener redirects about a hundred times per link created. A product page might be read a thousand times per edit. When your estimate shows reads dominating, say so, and tell the interviewer you will optimise the read path.

The naive design

The naive design sends every read to one database. A single well-indexed Postgres server might handle tens of thousands of simple queries a second, but far fewer once there are joins and sorts. Writes compete for the same CPU and memory, and connection counts run out. At forty thousand reads a second, latency climbs and then requests start timing out.

one Postgres box, indexed reads:
  roughly 10k-50k simple QPS
  far fewer for joins and sorts

need 40,000 reads/s at peak
+ connection limits (hundreds)
+ writes compete for the
  same CPU and buffer cache

→ latency climbs, then timeouts

Move 1: fix the query

Move one is free: make each read cheap. Add the index that matches the query, see Concepts episode seventeen. Remove N plus one patterns, where a list page fires one query per row. Select only the columns you need, and paginate with a cursor instead of a huge offset. Sometimes denormalising, like storing the author name on the post, removes a join from the hottest path.

Move 2: read replicas

Move two: read replicas. The primary takes every write and streams its change log to several copies; reads are spread across them, so five replicas give roughly five times the read capacity. The catch is replication lag. It is usually milliseconds, but under load it can be seconds, and a user who edits their profile and refreshes might see the old value. Concepts episode twenty covers replication.

The standard fix is read-your-writes for the person who just wrote. For about ten seconds after a write, route that user's reads to the primary, or remember the log position of their write and only read from a replica that has reached it. Everyone else can tolerate a second of lag. That one sentence shows you understand replication, not just the diagram.

Move 3: cache

Move three, the big one: a cache. With cache-aside, the app checks Redis first. On a miss it reads the database, then stores the result with an expiry. If ninety-five percent of reads hit, forty thousand reads a second becomes two thousand at the database. A single Redis node serves around a hundred thousand operations a second in under a millisecond. See Concepts episode eleven.

v = cache.get(key)
if v is null:
  v = db.query(...)
  cache.set(key, v, ttl=300)
return v

95% hit ratio on 40k reads/s
→ only 2,000 reach the DB
Redis node: ~100k ops/s, <1 ms

Invalidation

Caches go stale, so plan invalidation. A TTL bounds how stale anything can be. On a write, update the database, then delete the cache key rather than setting it, because two concurrent writers setting values can leave the older one in the cache. For stricter setups, a consumer of the database change log deletes keys, so no code path can forget.

Hot keys

Two traps. A stampede: a hot key expires and five thousand requests miss at the same instant and hammer the database. Fix it with request coalescing, so one request fetches and the rest wait, plus jittered expiry and background refresh. A hot key: one celebrity's profile lands on a single cache shard. Add a tiny in-process cache in front, or store several copies under suffixed keys.

Move 4: CDN

Move four: if many users get identical bytes, serve them from a CDN. Images, video, scripts, and even public API responses with the right cache headers. An edge hit costs tens of milliseconds and zero load on your origin. Purge on publish, or better, put a version in the URL so new content simply has a new address. Concepts episode twelve goes deeper.

Move 5: precompute

Move five: precompute. If every read does the same heavy computation, do it once at write time. Keep a like count column instead of counting rows. Fan a post out to followers' timelines so reading a feed is one lookup. Keep a leaderboard in a sorted set. Refresh a materialised view every minute for dashboards. You trade write cost and storage for very cheap reads.

Trade-offs

The trade-offs. Every copy, replica, cache or edge, adds staleness, so state the freshness budget, like a few minutes for a product description and zero for a bank balance. A cache costs memory and can fail; after a restart it is cold and the database takes the full load, so warm it or rate limit misses. Precomputing makes writes heavier. And sharding is for when writes or data outgrow one primary, not reads.

Where it shows up

You will use this in almost every problem. The URL shortener redirect path is a textbook cache plus replicas. Pastebin and YouTube push content to a CDN. News feed and Twitter precompute timelines. E-commerce caches product pages. Yelp caches nearby results by area. Whenever the read path is the hot path, walk through these moves.

Say it like this

Here is the phrasing. Reads are a hundred times writes, so I will optimise the read path. First indexed queries. Then read replicas, with read-your-writes for the author. Then a Redis cache-aside with a five-minute expiry, deleting the key on write and coalescing misses. A CDN for media and public pages. And precomputed counts so nothing aggregates at read time.