Consistency on IT Comparison

Primary vs Replica Reads: Strong Consistency vs Read Scaling

Sun, 06 Sep 2026 09:47:10 +0900

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

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

Sync vs Async Replication: When the Write Actually Commits

Sun, 06 Sep 2026 09:39:49 +0900

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

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

Consistency vs Availability: The CAP Theorem Tradeoff

Sun, 06 Sep 2026 09:35:36 +0900

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

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)