Consistency Concepts in System Architecture

Consistency Concepts: The CAP Theorem Reality In a distributed system, you are forced to balance the CAP Theorem (Consistency, Availability, and Partition Tolerance). Because network partitions are inevitable in any large-scale system, the real debate is how to handle Consistency —ensuring that all users see the same data at the same time. 1. Strong Consistency Strong Consistency guarantees that after an update completes, any subsequent access will return the updated value. It makes the distributed system behave as if it were a single-node database. How it works: Before a write is considered "successful," the system ensures the update has been propagated to a majority (or all) replicas. The Trade-off: High latency. The system must wait for network round-trips to all nodes before confirming the write. It also reduces availability; if the network is partitioned and the system cannot reach a majority, it must refuse all writes to prevent inconsistency. 2. Eventual Consistency Eventual Consistency is a weaker consistency guarantee. It allows the system to be highly available and performant by not requiring updates to propagate immediately. How it works: A write is accepted by a node and acknowledged to the user immediately. The system then propagates that update to other nodes in the background. The Reality: For a short window of time (the "inconsistency window"), different users may see different values. The system guarantees that if no new updates are made, all replicas will eventually match. Production Use: Used in systems like DNS, Amazon S3, and social media feeds, where performance and availability are prioritized over immediate global state sync. 3. Split Brain Problem The Split Brain problem occurs when a network failure causes a cluster to divide into two or more independent, unreachable partitions. The Conflict: If both partitions believe they are the "leader" of the cluster and continue accepting writes, the data will diverge permanently. When the network partition heals, you are left with two conflicting versions of the truth. The Prevention: Quorums: As we discussed, require a majority of nodes ( $N/2 + 1$ ) to elect a leader or commit a write. If a cluster is "split," the smaller side will fail to reach a majority and stop accepting writes. Fencing: Use a system like ZooKeeper to revoke the "lease" or "authority" from the nodes in the minority partition. 4. Vector Clocks In distributed systems, it is difficult to determine the order of events when multiple nodes update data concurrently. Vector Clocks are a data structure used to track causality and detect conflicts. The Mechanics: Each node maintains a list of "version numbers" (a counter) for every other node in the cluster. Detecting Conflicts: If version A is "greater" than version B, A is the newer update. If version A and version B are "incomparable" (e.g., node 1 says version 2, node 2 says version 1), the system knows a concurrent update conflict has occurred. Resolution: When a conflict is detected, the application can either merge the versions automatically (if possible) or force the user to resolve the conflict (like a Git merge conflict). Consistency Reference Matrix Concept Consistency Level Primary Benefit Risk Strong High Predictability, ACID integrity. High latency, lower availability. Eventual Low High speed, high availability. Risk of stale or conflicting data. Split Brain N/A (System Failure) Data divergence, corruption. Vector Clocks (Conflict Detection) Tracks causality. Metadata overhead.