Replication & read scaling
Keep copies of your data on multiple nodes for availability and read throughput.
Visual model
Write once, read from copies
Leader-follower replication
The common setup has one leader that accepts writes and streams each change to its followers.
Followers serve reads, so adding replicas increases read capacity. A follower can also replace the leader after a failure.
Replication is usually asynchronous, so followers may lag by milliseconds or seconds. This causes the classic 'I wrote it, but my next read cannot see it' bug.
When that matters, read your own writes from the leader or a synchronous replica.
See it
A successful write can still look missing
Trade-offs and other modes
Synchronous replication waits for a replica before confirming a write.
This protects data when the leader fails, but increases latency and depends on the replica being available.
Many systems use one synchronous replica and several asynchronous ones to balance the trade-off.
Multi-leader and leaderless setups accept writes in several places. This helps availability and geographic distribution.
The cost is conflict resolution. Use these modes only for a concrete need.
Key takeaways
- Read replicas scale reads and provide failover. Try them before sharding.
- Async replication creates replica lag. Route read-after-write traffic to the leader when correctness requires it.
- Synchronous replication trades latency for durability. Mix sync and async to balance them.