Read replicas

Followers that receive the leader's changes and serve reads. They scale read-heavy workloads cheaply, but replication lag means a user may not see their own recent write unless those reads go to the leader.

Where it shows up in real systems

  • Relational database

    The primary handles every write; read replicas add read capacity but lag slightly behind, so a user may not see their own write. A Multi-AZ standby takes over in about a minute if the primary fails. Sharding multiplies write capacity, but a bad shard key creates a hot shard. Without connection pooling, many app instances exhaust the connection limit.

    In production: PostgreSQL (Amazon RDS, Aurora), MySQL, Azure SQL Database, Cloud SQL, Citus, Vitess

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox