Read Replicas

In technical terms

The primary streams committed changes; replication lag stays single-digit milliseconds in-region but spikes under write pressure, large transactions, and especially during failover. Routing is a read-write split in the driver or proxy; correctness-critical reads pin to the primary or carry a session/version token to preserve read-your-writes.

Why it appears in interviews

It is the default first scaling lever, so design questions check whether you know its failure shape: which screens must be fresh (confirmations, dashboards right after submit), and what staleness the product will tolerate everywhere else.

The common misconception

Replicas are not backups. Failover to a lagging replica loses the tail of committed writes; and not every read is safe on a replica: a “save → redirect ↔ not found” flow is a replication bug wearing a product costume.

Trade-offs & when it hurts

Each replica adds read capacity and an HA path at the cost of lag windows, per-query routing decisions, and failover ambiguity (promote with data loss, or wait for sync. A product decision). Cheaper and simpler than sharding; the two compose later.

How to show it in an interview

Turn replicas into a routing rule with an exception: “Reads go to replicas, except in-session after a write: 60 seconds pinned to primary so the confirmation page always sees its own commit, and the page for replica lag is the alert, not a dashboard decoration.” The exception is the senior sentence; everyone else forgets it.

Questions this concept earns

• After checkout the dashboard shows no order. Diagnose it down to the routing layer.
• Lag just hit 30 seconds under load: what alerts, and what do users experience?
• The primary died with lagging replicas: promote now and lose the tail, or wait? Who signs off?

Related