Replication

Overview When two replicas accept concurrent writes to the same key, a system must reconcile them. Last-Write-Wins picks a single winner by timestamp and discards the rest, while Merging combines both writes into a new value using domain-specific or CRDT logic. Comparison Diagram Last-Write-WinsMergingWrite At=10, val=1Write Bt=12, val=2val = 2(highest timestamp wins)Write A silently discardedWrite At=10, val=1Write Bt=12, val=2{A:1, B:2}(both values combined)No data lost, app may reconcile Comparison Table Aspect Last-Write-Wins Merging Conflict trigger Fires when two writes to the same key arrive with overlapping validity, regardless of content Fires the same way, but treats both writes as valid inputs rather than competitors Resolution mechanism Compares timestamps (or version numbers) and keeps the highest one Applies a merge function, CRDT join, or three-way diff to combine both values Data/metadata required A reliable clock or monotonic counter per write Version vectors, causal history, or a semantically defined merge operation Application involvement None — resolution is automatic and content-agnostic Requires the app or data structure to define what ‘combining’ means Outcome for the losing write Discarded entirely, no trace remains Incorporated into the final merged state, nothing is dropped Consistency guarantee Deterministic convergence, but the winner may be arbitrary relative to causality Deterministic convergence that also respects the semantics of both updates Performance overhead Minimal — a single comparison per conflict Higher — merge logic, extra metadata, and sometimes multi-way comparisons Failure mode Silent data loss under clock skew or concurrent writes at the same timestamp Unresolvable merge conflicts that surface to the application or user Key Differences LWW resolves conflicts purely by comparing timestamps, keeping only one write. Merging combines concurrent writes using a merge function or CRDT join instead of picking a single winner. LWW can cause silent data loss when clocks skew or writes race within the same tick. Merging needs semantic knowledge of the data type to combine values correctly. LWW adds negligible overhead per write; merging trades that simplicity for correctness under concurrency. When to Use Each Last-Write-Wins ...

Overview Strong and eventual consistency describe how distributed systems handle replicated data after a write. Strong consistency guarantees every read reflects the latest write by blocking until replicas agree, while eventual consistency returns immediately and lets replicas converge in the background. The choice trades write latency and availability against read freshness. Comparison Diagram Strong ConsistencyEventual ConsistencyClientPrimaryReplica 1Replica 2write blocks untilall replicas ackAny read, any replica,always returns latest valueClientNodeReplica 1Replica 2ACK immediateasync, delayedRead from Replica 1 mayreturn stale value until t+Δ Comparison Table Aspect Strong Consistency Eventual Consistency Write acknowledgment Ack returned only after write is durably applied to all (or a quorum of) replicas Ack returned as soon as the write hits the local/primary node Replication propagation Synchronous — write blocks until replicas confirm Asynchronous — replication happens in the background Read guarantee Every read reflects the most recent write (linearizable) Reads may return stale data until replicas converge Conflict handling Prevented upfront via consensus/locking that serializes writes Resolved after the fact via LWW, vector clocks, or CRDTs Write latency Higher — pays network round-trip cost to replicas/quorum Lower — commits locally before propagating Behavior under partition Unavailable or degraded if quorum can’t be reached (CP) Stays available, serving from whichever replica is reachable (AP) Typical mechanism Consensus protocols like Paxos/Raft, synchronous quorum writes Gossip protocols, anti-entropy repair, background sync Typical use cases Banking ledgers, inventory counts, leader election Social feeds, DNS, shopping carts, CDN caches Key Differences Strong consistency blocks the write until a quorum confirms; eventual consistency acks after a local commit. This is the classic CAP tradeoff: strong favors consistency during a partition, eventual favors availability. Strong relies on consensus protocols like Raft; eventual relies on background anti-entropy repair. Only strong consistency guarantees read-after-write; eventual consistency allows a stale-read window. When to Use Each Strong Consistency ...