Data Consistency Levels

📋 Overview

In distributed systems, data consistency defines the rules for how and when updates to a data item are visible to all users and replicas. Because of the CAP theorem, systems must trade off consistency for availability and latency. Consistency levels range from "Strong" (the most strict) to "Eventual" (the most performant), and choosing the right level is a fundamental architectural decision based on the application's tolerance for stale data.

---

🏗️ Core Principles & Characteristics

• Strong Consistency: After an update, any subsequent access will return the updated value. Requires global coordination (e.g., Two-Phase Commit or Paxos).
• Eventual Consistency: If no new updates are made, all accesses will eventually return the last updated value. High availability, low latency.
• Causal Consistency: If process A has communicated to process B that it has updated a data item, a subsequent access by process B will return the updated value.
• Read-Your-Writes Consistency: A user will always see their own updates immediately, even if other users see stale data for a short window.
• Monotonic Reads: If a user has seen a particular value, they will never see an "older" value later.

---

⚖️ Trade-offs: Pros & Cons

• Strong Consistency:
  • Pros: Simple programming model; no stale data anomalies.
  • Cons: High latency; system becomes unavailable if a network partition occurs (CP system).
• Eventual Consistency:
  • Pros: Extremely fast; highly available (AP system); handles massive scale.
  • Cons: Complex application logic (must handle conflicts/stale reads); poor user experience if not managed (e.g., deleted post reappearing).

---

🌍 Real-World Implementation

• Banking Transactions: Require Strong Consistency to ensure no double-spending or negative balances.
• Social Media Likes/Comments: Typically use Eventual Consistency. It doesn't matter if a "Like" count is off by 1 for a few seconds.
• Amazon S3: Switched from eventual to Strong Consistency for List/Read operations in 2020 to simplify developer workflows.
• Cassandra/DynamoDB: Allow developers to choose the consistency level per query (e.g., ConsistencyLevel.QUORUM).

---

💡 Interview "Gotchas" & Tips

• PACELC Theorem: An extension of CAP. It states that even when there is no partition (P), there is a trade-off between Latency (L) and Consistency (C).
• The "Quorum" Calculation: If you have N replicas, a write to W nodes and a read from R nodes is strongly consistent if W + R > N.
• Inconsistency Window: Ask yourself: "What is the maximum time a user can see stale data?" (e.g., DNS propagation can take 24 hours).
• Sticky Sessions: A common way to provide Read-Your-Writes consistency by ensuring a user always hits the same replica for their session.

---

📐 Suggested Architecture Primitives

• Consensus Algorithm: (Raft/Paxos) for strong consistency.
• Gossip Protocol: For propagating updates in eventually consistent systems.
• Vector Clocks: To resolve conflicts in causal consistency models.
• Quorum Read/Write: Configurable levels in NoSQL databases.