Read Replicas & Replication Lag

How Read Replicas Work

In most applications, data is read far more often than it is written. Read replicas (also called primary-replica or leader-follower replication) solve this by distributing read load.

1. The primary (leader) is the single server that accepts all write operations. It is the source of truth.
2. Replicas (followers) are read-only copies. They accept only SELECT queries.
3. The primary writes all changes to a transaction log (binlog in MySQL, WAL in PostgreSQL). Replicas continuously pull from this log and apply changes.
4. The application routes all writes to the primary and distributes reads across the replica pool.

If read traffic doubles, you don't scale the primary — you add another replica.

The Critical Trade-off: Replication Lag

Replication is almost always asynchronous. The primary acknowledges a write immediately, without waiting for replicas to confirm receipt. This creates replication lag — ranging from milliseconds to several seconds under heavy load.

Example: A user changes their username. The write goes to the primary. They are immediately redirected to their profile page. The SELECT hits a replica that hasn't received the update yet. They see their old username.

Mitigation (read-your-writes consistency): For operations where a user must immediately see their own write, route their reads to the primary for a short window (e.g., 30 seconds) after any write they perform.

Scenario	Good Fit?	Rationale
High read-to-write ratio (blogs, catalogs, feeds)	Excellent	Add replicas to absorb read volume; primary handles writes easily
Read-after-write consistency required	Use with caution	Route that user's reads to primary for a short window post-write
Analytics and reporting	Excellent	Dedicate a replica to long-running queries; isolates them from live traffic
High availability	Good	A replica can be promoted to primary if the primary fails
Write-heavy workloads	Poor	Replicas do nothing for write bottlenecks; all writes still hit one primary