Read Replicas

DatabasesMiddb

The Question

What are read replicas and when would you use them?

What a Strong Answer Covers

• Replication lag
• read from leader for freshness.

Senior-Level Answer

A read replica is a database instance that maintains a continuously updated copy of a primary (writer) instance and serves read-only queries. The primary streams its write-ahead log (WAL) or binlog to replicas, which apply the changes asynchronously — or synchronously in the case of synchronous replication.

The primary use case is **read scaling**. Most web applications are read-heavy (80–95% reads). A single primary can become a bottleneck. Adding read replicas distributes SELECT load horizontally. Replicas can also run expensive analytics or reporting queries without affecting primary performance.

**Replication lag** is the central trade-off. Asynchronous replicas apply changes after the primary commits — typically milliseconds behind, but potentially seconds during high write load or network issues. This means a client that reads from a replica immediately after a write may see stale data. Common mitigation: route the user's own read-after-write to the primary (read-your-writes consistency), or use a short delay before reading from a replica.

**When to use read replicas:** - Analytics or reporting queries that would saturate the primary - High read/write ratio with reads exceeding primary capacity - Geographic distribution — place replicas closer to users in different regions - Offloading backups — take snapshots from a replica to avoid locking the primary

**When not to use read replicas:** - Write-heavy workloads — replicas don't help; consider sharding instead - Strict read-after-write consistency requirements — either route all reads to primary or use synchronous replication (which adds write latency) - As a replacement for proper indexing — a poorly indexed query is slow on a replica too

Most cloud databases (AWS RDS, Google Cloud SQL, PlanetScale) support read replicas with simple configuration. Connection poolers like PgBouncer or application-level routing (separate read/write connection strings) handle traffic distribution. Multi-region replication (e.g., Aurora Global Database) uses the same model with higher lag due to cross-region network latency.

Promotion: if the primary fails, a replica can be promoted to primary. Failover time depends on replication mode — synchronous replicas have zero data loss; async replicas may lose the last few seconds of commits.

What Separates a 2/3 from a 3/3

Common Mistakes

• Presenting read replicas as a solution for write-heavy workloads — they only help with reads.
• Not addressing replication lag — treating replicas as perfectly consistent copies of the primary.
• Suggesting replicas as a substitute for proper indexing or query optimization.
• Ignoring read-after-write consistency issues — a user who just posted a comment then immediately reads and sees it missing.

Follow-Up Questions

• A user creates an account and is immediately redirected to a page that reads their profile — how do you avoid showing stale data? — Route the immediate post-write read to the primary; use a session flag to indicate the user just wrote; or use synchronous replication with the trade-off of higher write latency.
• How would you handle read replica lag during a traffic spike? — Monitor replica lag metric; implement circuit-breaker to route all traffic to primary if lag exceeds threshold; scale vertically or add more replicas.
• What is the difference between a read replica and a standby (hot standby)? — Hot standby is for failover — it applies WAL synchronously and can promote to primary with zero data loss; read replicas are primarily for scaling reads and may lag.
• How do read replicas interact with connection pooling? — You typically maintain separate pools for read and write connections; the application or ORM routes based on query type; PgBouncer can front separate primary and replica pools.

Related Questions

• ACID
• Indexes
• Clustered vs Non-clustered
• Isolation Levels
• Normalization