Splitting the Workload
Think of a busy library. One librarian (the Primary) handles all new book acquisitions and catalog updates. Several other librarians (Replicas) each have an identical copy of the catalog and spend their time answering patron lookup questions. The head librarian periodically sends updates to the others so their catalogs stay current.
For many applications, read operations (SELECT) vastly outnumber write operations (INSERT, UPDATE, DELETE). A news site might have 99 reads for every 1 write. A social media feed is similar. We can exploit this asymmetry by creating Read Replicas.
- One Primary: A single server is designated as the Primary (historically called "master"). All write operations must go to the Primary. It is the single source of truth.
- Multiple Replicas: The Primary continuously streams its changes — encoded in the Write-Ahead Log (WAL) — to one or more Replica servers over the network. Each replica replays those changes to maintain a near-identical copy of the data. Replicas serve only read queries.
Your application is configured to send writes to the Primary's hostname and distribute reads across the Replicas' hostnames, massively increasing read throughput without changing the database engine itself.
The Catch: Replication Lag
The data doesn't appear on the replicas instantly. It takes time to ship the WAL records over the network and for the replica to replay them. This delay is called Replication Lag.
Lag usually measures in milliseconds under normal conditions, but under heavy write load or network degradation, it can grow to seconds or even minutes. This leads to Eventual Consistency: if a user posts a comment and immediately refreshes the page, their read request might hit a replica that hasn't received the new comment yet, making it appear to have vanished. This is called a read-your-own-write consistency violation.
The standard mitigation is to route specific, consistency-sensitive reads — like "show me the thing I just created" — directly to the Primary. Only reads that can tolerate slight staleness go to replicas. Most ORMs and database drivers support this routing pattern natively.
Interviewers frequently ask: "How do you handle the case where a user writes data and immediately reads it back, but gets stale data?" The answer is read-your-own-write consistency, implemented by routing post-write reads to the Primary for a short window, or by using a session token that tells the replica to wait until it has replicated up to a specific WAL position (PostgreSQL's pg_current_wal_lsn() / pg_last_wal_replay_lsn() pattern). Saying "just always read from Primary" is technically correct but defeats the purpose of replicas — a senior answer acknowledges the trade-off.