Read replicas

Most applications read far more than they write: feeds, profiles, product pages. When the database becomes the bottleneck and most of its work is reads, the first move after caching is to copy the database and spread reads across the copies.

How replication works

One server is the primary (or leader). It takes every write. It records each change in a log (Postgres calls it the WAL, MySQL the binlog) and streams that log to replicas (followers), which apply the same changes in the same order.

The application, a proxy or the database driver sends writes to the primary and spreads reads across the replicas.

Try it. This design's primary is overloaded by reads. Click Read replica and raise its instances (each instance is another replica) until the design holds.

Replication lag

Replication is usually asynchronous: the primary commits and replies to the client, then ships the change. Replicas trail by milliseconds normally, and by seconds or minutes when they're overloaded, a long query blocks them, or the network is slow.

That means a read from a replica can return data that's slightly out of date. Often that's fine: a like count or a product description a second old harms nobody. Sometimes it's visibly wrong:

• Reading your own writes. You post a comment, the page reloads from a replica, and your comment is missing.
• Going back in time. Two reads hit different replicas, and the second shows older data than the first.

Coping with lag

Replicas versus caches

Both serve reads, and designs often have both. A cache is faster and cheaper per read and holds only hot data, but it needs invalidation logic. A replica holds everything, answers any query including complex ones, and stays fresh automatically within its lag. Reach for a cache for hot key lookups and replicas for broad read load like search pages, reports and long-tail data.