What are the different types of consistency models in distributed databases?

Distributed databases use consistency models to define how and when data changes become visible across nodes. The three primary models are strong consistency, eventual consistency, and causal consistency, with variations like session consistency and sequential consistency addressing specific use cases. Each model balances trade-offs between data accuracy, system performance, and availability.

Strong consistency ensures all nodes see the same data at the same time. When a write operation completes, subsequent reads from any node will return the updated value. This model prioritizes data accuracy over performance, often using protocols like two-phase commit or distributed transactions to coordinate updates. For example, financial systems (e.g., banking apps) require strong consistency to prevent double-spending or incorrect balances. However, this comes with higher latency, as nodes must synchronize before confirming a write. Systems like Google Spanner and traditional relational databases often implement strong consistency.

Eventual consistency allows temporary discrepancies between nodes, guaranteeing that all copies will converge to the same state if no new updates occur. This model prioritizes availability and partition tolerance, making it suitable for systems where low latency is critical. Social media platforms (e.g., Twitter or Instagram) use eventual consistency for features like likes or comments, where minor delays in propagation are acceptable. Amazon DynamoDB and Apache Cassandra support this model, using mechanisms like hinted handoffs or read-repair to resolve conflicts. However, developers must handle scenarios where stale data might be read during the convergence window.

Causal consistency and its variants address specific needs. Causal consistency ensures that causally related operations (e.g., a reply to a post) are seen in the correct order, even if unrelated operations appear out of order. This is useful in collaborative apps like Google Docs, where edits depend on prior changes. Session consistency guarantees that a user’s interactions within a single session (e.g., a shopping cart) remain consistent, even if other users see stale data. Sequential consistency ensures all nodes agree on the order of operations, useful in distributed queues or logs. Monotonic reads, a weaker model, ensures that once a client reads a value, subsequent reads will never show older data. These models offer flexibility for developers to prioritize specific aspects of consistency without the overhead of strong consistency.