← Study Notes Scalability


Scalability

Replication

Copying data to multiple nodes for read scaling and fault tolerance — a primary takes writes and streams them to replicas that serve reads, or multi-primary for write availability. Failover promotes a replica when the primary dies. The catch is replication lag: async replicas can serve slightly stale reads, so route read-your-writes carefully.


Purpose

Replication maintains copies of data on multiple nodes: typically one primary accepts writes and streams changes to replicas that serve reads. It buys two things at once — read throughput (spread queries across replicas) and fault tolerance (promote a replica when the primary dies).

When to Use It

Read-heavy applications offloading queries to replicas; high-availability setups with automatic failover; geographic distribution placing replicas near users; and safe operational reads — analytics and backups running against a replica instead of the primary.

Trade-offs

Asynchronous replication introduces lag: a replica may be seconds behind, so a user who writes then immediately reads from a replica can see their change missing (the read-your-writes problem). Synchronous replication closes the gap but adds write latency; async failover can lose the last moments of writes.

Implementation

Use the database's native streaming replication; monitor lag as a first-class metric. Route writes and consistency-critical reads to the primary, bulk reads to replicas — session pinning after a write is the common fix for read-your-writes. Test failover regularly; an untested promotion procedure is a fictional one.