Database-Replication

Overview In a replicated database, read queries can be routed to the primary node or to one of the read replicas. The choice trades guaranteed data freshness for the ability to scale read throughput and reduce load on the write path. Comparison Diagram ClientPrimaryhandles all writesReplicaread-only copyasync replication (lag)writeread (fresh)read (maybe stale)single node, no lagscales out horizontally Comparison Table Aspect Primary Reads Replica Reads Read target Always the single primary node Any of one or more read replicas Consistency guarantee Read-your-writes, strongly consistent Eventual consistency, may lag behind writes Replication lag exposure None, reads the current write state directly Exposed to lag, from milliseconds to seconds Contention with writes Reads compete with writes for CPU, locks, and I/O Writes on primary don’t directly compete with replica reads Read throughput scaling Bounded by single node capacity Scales horizontally by adding more replicas Latency profile Consistent, no wait for replication to catch up Can be lower if replica is geographically closer, but variable under lag Failover behavior Node failure requires promotion and brief write/read outage Load balancer can reroute to another healthy replica Typical use case Financial transactions, read-after-write flows, admin views Analytics, reporting, public APIs, dashboards Key Differences Primary reads guarantee read-your-writes consistency; replica reads may return stale data due to lag. Replica reads scale horizontally by adding read replicas; primary reads are bottlenecked by a single node. Primary reads compete with write traffic for resources; replica reads isolate read load via replication. Replication lag on replicas ranges from milliseconds to seconds depending on network and write volume. Failover on the primary causes brief unavailability; replica failures are masked by load balancing across peers. When to Use Each Primary Reads ...

Overview Synchronous and asynchronous replication differ in exactly one moment: when the primary tells the client a write succeeded. Sync replication waits for the replica to confirm before acknowledging, while async replication acknowledges immediately and copies the data afterward. That single timing difference cascades into everything else — latency, throughput, and how much data you can lose on failover. Comparison Diagram Sync ReplicationAsync ReplicationClientPrimaryReplica1. write2. replicate3. ack4. commitClient waits for step 3ClientPrimaryReplica1. write2. commit3. replicate laterClient returns at step 2 Comparison Table Aspect Sync Replication Async Replication Write acknowledgment Waits for replica confirmation before committing Commits on primary alone, replicates after Commit latency Includes network round-trip to replica Bound only by primary’s local write Data consistency Replica is always up to date at commit time Replica can lag behind primary momentarily Throughput under load Degrades as replica distance or count grows Unaffected by replica speed or distance Replica or network failure Writes block or fail until replica responds Writes continue uninterrupted on primary Failover data loss None — replica always has the committed write Possible — unreplicated writes are lost Replication lag monitoring Not applicable — lag is structurally zero Critical — must track and alert on lag Key Differences Commit timing is the root difference: sync waits, async doesn’t Sync trades latency for a zero-data-loss guarantee on failover Async trades durability for consistently fast local commits Multi-region setups favor async since round-trip time would make sync commits too slow Async requires active lag monitoring that sync simply doesn’t need When to Use Each Sync Replication ...