Database read replicas are a fundamental scaling pattern: route writes to a primary database, replicate changes to one or more read-only replicas, and distribute read traffic across them. This architecture appears in everything from Postgres clusters to global content delivery systems. The appeal is obvious—you can scale read capacity horizontally without expensive sharding or coordination overhead.

But replication introduces a subtle problem that surfaces in production: lag. The replica is always slightly behind the primary, sometimes by milliseconds, sometimes by seconds or more. This delay creates a consistency gap that applications must handle explicitly.

How Replication Works

Most databases replicate by shipping a log of changes from the primary to replicas. Postgres uses Write-Ahead Log (WAL) streaming, MySQL uses binary logs, MongoDB uses an oplog. The primary writes a transaction, appends it to the log, and asynchronously sends it to replicas. Replicas apply the log entries in order, eventually catching up.

The gap between when a write commits on the primary and when it appears on a replica is replication lag. Under normal conditions, lag is negligible—single-digit milliseconds. But network hiccups, large transactions, or heavy replica load can push lag into seconds. If a replica falls too far behind, it may need to pause and resync, creating even longer delays.

The Read-After-Write Problem

The most common place lag surfaces is read-after-write consistency. A user submits a form, the application writes to the primary, then immediately redirects and reads from a replica. If the replica hasn’t caught up, the user sees stale data—or worse, their own write appears to vanish.

This isn’t a bug in the database. It’s the expected behavior of asynchronous replication. The system is eventually consistent: given enough time, all replicas converge to the same state. But “eventually” can be uncomfortably long for user-facing features.

Mitigation Strategies

Applications handle replication lag in a few common ways. The simplest is sticky sessions—after a write, route that user’s subsequent reads to the primary for a short window, then resume using replicas. This guarantees the user sees their own writes at the cost of bypassing replica capacity temporarily.

Another approach is to track replication position. Postgres exposes the current WAL position on both primary and replicas. After a write, the application can note the position and only read from replicas that have caught up to at least that point. This requires more bookkeeping but avoids overloading the primary.

Some systems read from the primary by default and only use replicas for non-critical queries—analytics, search indexing, or background jobs where slight staleness is acceptable. This sidesteps the consistency problem by matching read path to tolerance level.

Lag as a Signal

Replication lag is also an operational metric. Sustained high lag indicates a problem: the replica can’t keep up with write volume, the network link is saturated, or a long-running transaction is blocking replay. Monitoring lag and alerting on thresholds is standard practice in production environments.

Modern managed database services expose lag as a first-class metric. Cloud providers often route reads automatically based on lag, excluding replicas that have fallen too far behind. This makes the system more forgiving but doesn’t eliminate the consistency gap—it just hides it behind smarter routing.

When Replicas Aren’t Enough

Read replicas work well when reads vastly outnumber writes and slight staleness is tolerable. But they don’t solve write scaling, and they complicate application logic. For workloads that need strong consistency across all reads, the primary remains the bottleneck. That’s when teams look toward multi-primary replication, distributed consensus systems, or sharding—each with their own trade-offs.

Replication lag isn’t a flaw. It’s the price of horizontal read scaling without expensive coordination. Understanding when and how it surfaces is essential for building systems that scale predictably without surprising users.