Consensus Protocols

Byzantine Fault Tolerance (BFT) is the property of a distributed system to reach consensus correctly even when some of its components fail in arbitrary, potentially malicious ways (Byzantine failures), without requiring a trusted central authority.

• Core Challenge: Handles not just crashes but also nodes that send contradictory or incorrect information.
• Key Algorithms: Practical Byzantine Fault Tolerance (PBFT) is a classic solution, while newer blockchain protocols like Tendermint use BFT-based consensus.
• Use Case: Essential for permissionless blockchains and high-security financial systems where participants cannot be fully trusted.

Eventual consistency is a data consistency model used in distributed systems where, in the absence of new updates, all replicas of a data item will eventually converge to the same value. It trades strong consistency for higher availability and partition tolerance.

• CAP Theorem: This is the "C" (consistency) sacrifice made to achieve "AP" (Availability & Partition tolerance).
• Common in: Dynamo-style databases (e.g., Amazon DynamoDB, Apache Cassandra) and DNS.
• Mechanism: Uses techniques like read repair and hinted handoff to propagate updates asynchronously.

Strong consistency is a data consistency model that guarantees any read operation on a distributed system returns the most recent write for a given data item. The system appears as a single, up-to-date copy.

• Linearizability: A strong form of consistency where operations appear to occur instantaneously at a single point in time.
• Trade-off: Often requires coordination (e.g., via a leader or quorum), which can impact latency and availability during network partitions.
• Use Case: Critical for systems like financial ledgers or primary database systems where stale reads are unacceptable.

Conflict-Free Replicated Data Types (CRDTs) are data structures designed for distributed systems that can be replicated across multiple nodes, updated independently and concurrently without coordination, and are mathematically guaranteed to converge to the same state.

• Core Principle: Operations are commutative, associative, and idempotent, ensuring deterministic merging.
• Types: State-based (convergent) and operation-based (commutative).
• Applications: Ideal for collaborative applications (like Google Docs), distributed counters, sets, and registers in eventually consistent systems.

A vector clock is a logical timestamp mechanism used in distributed systems to capture the partial ordering of events and detect causal relationships between them. Each node maintains a vector of counters, one for every other node in the system.

• Causality Tracking: Can determine if event A happened-before event B, or if they are concurrent.
• Versus Lamport Clocks: Provides more information than a simple Lamport clock, enabling detection of concurrent updates.
• Use Case: Foundational for versioning in distributed databases (e.g., Amazon Dynamo, Riak) to resolve update conflicts by understanding event causality.

ACID compliance is a set of four properties—Atomicity, Consistency, Isolation, and Durability—that guarantee reliable processing of database transactions, ensuring data validity despite errors, power failures, or other system faults.

• Atomicity: A transaction is all-or-nothing.
• Consistency: A transaction brings the database from one valid state to another.
• Isolation: Concurrent transactions do not interfere.
• Durability: Committed transactions persist.
• Context: Traditional relational databases (e.g., PostgreSQL, MySQL) are ACID-compliant, providing the strongest consistency guarantees for single-node or tightly-coupled distributed systems.