Consistency Model

Strong consistency guarantees that any read operation returns the value from the most recent write operation, as perceived by all clients. It provides a linearizable view of the data, as if the system were a single node. This model is essential for systems where data accuracy is non-negotiable, such as financial ledgers or primary key generation.

• Mechanism: Typically enforced via synchronous replication and quorum-based reads and writes.
• Trade-off: Achieves perfect data accuracy at the cost of higher latency and reduced availability during network partitions, as dictated by the CAP theorem.

Eventual consistency is a model where, in the absence of new updates, all replicas in a distributed system will eventually converge to the same state. Reads may temporarily return stale data, but the system guarantees that updates will propagate to all nodes. This is the default model for many globally distributed databases and content delivery networks (CDNs).

• Mechanism: Relies on asynchronous replication and background synchronization protocols like gossip protocols.
• Trade-off: Maximizes availability and partition tolerance (from the CAP theorem) while accepting temporary inconsistency, which is acceptable for use cases like social media feeds or product catalogs.

Causal consistency is a model that preserves the "happened-before" relationships between operations. If operation A causally affects operation B (e.g., a reply to a comment), then any node that sees B must also see A. It is stronger than eventual consistency but weaker than strong consistency.

• Mechanism: Requires tracking causal dependencies, often using vector clocks or version vectors to tag operations.
• Use Case: Ideal for collaborative applications (like Google Docs), chat systems, and comment threads where logical order matters more than absolute global recency, but strict linearizability is too costly.

Session consistency guarantees that a client will observe its own writes and a monotonic sequence of reads within a single session. It prevents a user from seeing their data revert to an older state during their interaction with the system, even if other users see slightly stale data.

• Mechanism: The system binds a client to a specific replica or tracks a session token to ensure read-your-writes and monotonic read guarantees for that session.
• Use Case: Critical for user-facing web applications (e.g., e-commerce carts, user profiles) to provide a predictable and non-confusing experience for an individual user, without the global overhead of strong consistency.

Read-your-writes consistency is a specific guarantee that a client will always see the updates it has made, even if those updates have not yet propagated globally. It is a subset of session consistency and a common minimum requirement for interactive applications.

• Mechanism: Often implemented by routing a user's subsequent requests to the same data replica that handled their write or by attaching a version token to the client.
• Example: After posting a status update on a social platform, you immediately refresh your page and see the post. Another user in a different region might not see it for a few seconds, but your view is guaranteed to be consistent with your own actions.

Consistent prefix (or prefix consistency) ensures that reads will never see a state that "goes back in time." If a sequence of writes is applied in a certain order, any observer will see a prefix of that sequence, though they may see different prefixes at different times. It prevents nonsensical outcomes like seeing an answer before the question.

• Mechanism: Requires maintaining a partial order of updates, often managed by a primary node or through logical timestamps.
• Use Case: Fundamental for distributed messaging queues, news feeds, and blockchain systems where the order of events is critical for logical correctness, even if some followers are slightly behind the leader.

Strong consistency (or linearizability) is a model where any read operation returns the value from the most recent write operation, as perceived by all clients. It provides a single-system illusion.

• Mechanism: Often enforced via synchronous replication and quorum-based reads and writes.
• Trade-off: Higher latency for writes, as they must propagate to replicas before acknowledgment.
• Use Case: Financial systems, leader election, and distributed locks where absolute correctness is critical.

Eventual consistency is a model where, in the absence of new updates, all replicas will eventually converge to the same state. Reads may temporarily return stale data.

• Mechanism: Typically uses asynchronous replication.
• Trade-off: Favors low-latency writes and high availability over immediate consistency.
• Use Case: Social media feeds, DNS, and collaborative editing tools where temporary inconsistency is acceptable.

A quorum is the minimum number of nodes in a distributed system that must successfully participate in a read or write operation for it to be considered valid. It is the primary mechanism for enforcing consistency levels.

• Write Quorum (W): Number of nodes that must acknowledge a write.
• Read Quorum (R): Number of nodes queried for a read.
• Rule: For strong consistency, the condition R + W > N (where N is the replication factor) must hold, ensuring read and write sets overlap.

These are the two core data propagation methods that underpin consistency guarantees.

• Synchronous Replication: A write is only acknowledged after data is persisted on the primary node and all designated replica nodes. This ensures strong consistency but increases write latency.
• Asynchronous Replication: The primary node acknowledges a write immediately after local persistence. Replicas are updated in the background. This enables low-latency writes and high availability but risks data loss if the primary fails before replication completes.