Consistency

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 ...

Overview When a distributed system suffers a network partition, it must choose between consistency (every node sees the same data, even if that means rejecting requests) and availability (every request gets a response, even if the data might be stale). This CAP theorem tradeoff shapes how databases behave under failure and directly affects correctness guarantees versus uptime. Comparison Diagram Consistency (CP)Availability (AP)ClientClient503 blocked200 OK (stale)Node ANode BpartitionNode ANode BpartitionWaits for quorum, rejects requestGuarantee: no stale readsAnswers immediately from local dataGuarantee: no downtime Comparison Table Aspect Consistency (CP) Availability (AP) Normal operation (no partition) Behaves identically to any healthy cluster; all replicas agree Behaves identically to any healthy cluster; all replicas agree Behavior when a partition occurs Nodes that cannot confirm quorum stop responding All nodes keep responding regardless of quorum status Write handling during partition Writes are rejected or queued until enough replicas are reachable Writes are accepted locally and replicated once the partition heals Read handling during partition Reads are blocked or errored if the latest value can’t be confirmed Reads are served from whatever local replica is reachable, even if stale Client-facing failure mode Client sees a timeout or explicit error (e.g. 503) Client sees a successful response that may contain outdated data Data guarantee provided Linearizability - no two nodes ever disagree on current state Liveness - the system always answers, correctness may lag Recovery after partition heals Resumes cleanly; no conflicting writes existed since they were blocked Must reconcile diverging writes via vector clocks, LWW, or CRDTs Representative systems HBase, Zookeeper, MongoDB (default majority writes) Cassandra, DynamoDB, Riak Key Differences The tradeoff only bites during an actual network partition - outside of that, both behave the same. Consistency requires a quorum agreement before answering, which can mean refusing requests. Availability guarantees a response but risks returning stale data to the client. The choice determines whether you need a conflict resolution strategy for divergent writes after recovery. Many production databases offer tunable consistency, letting you pick per-operation rather than a single global stance. When to Use Each Consistency (CP) ...