Strong Consistency

Eventual consistency is a weaker guarantee where, in the absence of new writes, all replicas of a data item will eventually converge to the same state. It prioritizes availability and partition tolerance over immediate consistency.

• Key Trade-off: Accepts temporary read inconsistencies (stale data) for higher system availability, as defined by the CAP theorem.
• Common Use: DNS, social media feeds, and e-commerce shopping carts where minor delays in propagation are acceptable.
• Mechanism: Updates are propagated asynchronously; replicas reconcile state over time, often using mechanisms like Conflict-Free Replicated Data Types (CRDTs).

The CAP theorem (Consistency, Availability, Partition tolerance) is a fundamental principle stating a distributed data store can provide only two of three guarantees simultaneously during a network partition.

• Consistency (C): Every read receives the most recent write (equivalent to strong consistency).
• Availability (A): Every request receives a non-error response.
• Partition Tolerance (P): The system continues operating despite network failures that split nodes.
• Implication: A strongly consistent system (CP) may become unavailable during a partition to preserve linearizability, while an AP system sacrifices consistency for availability.

Linearizability is the strongest form of strong consistency. It guarantees that operations appear to take effect instantaneously and atomically at some point between their invocation and completion, preserving a real-time ordering across all clients.

• Strict Guarantee: Provides a single, globally consistent timeline of operations. If operation B starts after operation A completes, B must see A's effects.
• Implementation: Often requires a single leader or a consensus protocol like Raft or Paxos to serialize all operations.
• Distinction: All linearizable systems are strongly consistent, but not all strongly consistent systems (e.g., sequential consistency) are linearizable.

Byzantine Fault Tolerance (BFT) is a property of a distributed system that enables it to achieve consensus and maintain strong consistency even when some components fail arbitrarily (Byzantine faults) or act maliciously.

• Challenge: Tolerates not just crashes but incorrect, conflicting, or deceptive messages from faulty nodes.
• Protocols: Practical Byzantine Fault Tolerance (PBFT) is a classic state machine replication algorithm requiring a supermajority of correct nodes (e.g., 3f+1 nodes to tolerate f faults).
• Application: Critical for blockchain networks (e.g., Tendermint) and high-security financial systems where trust cannot be assumed.

Raft is a consensus algorithm designed for understandability, used to manage a replicated log and provide strong consistency (state machine replication) across a cluster of machines.

• Mechanism: Elects a single leader node that accepts client commands, replicates them to follower nodes, and commits them once a majority acknowledge.
• Strong Consistency Guarantee: All reads served by the leader are linearizable, as the leader has the complete, committed log.
• Use Case: The foundational consensus layer for distributed databases like etcd and TiKV, ensuring all replicas apply the same commands in the same order.

Conflict-Free Replicated Data Types (CRDTs) are data structures designed for eventually consistent systems that can be updated concurrently without coordination, guaranteeing automatic, deterministic conflict resolution.

• Contrast with Strong Consistency: CRDTs embrace eventual consistency; they do not provide the linearizable reads of strong consistency but ensure convergence without complex consensus.
• Operation: Based on mathematical properties (commutativity, idempotence) so operations can be applied in any order to reach the same final state.
• Application: Real-time collaborative applications (e.g., Google Docs), distributed counters, and sets where availability and partition tolerance are paramount.