# Data Consistency & Its Levels

Quick Reference: CAP Theorem | Isolation Levels | Priority Framework

# Quick Reference

# Clear Definition

Data Consistency refers to the guarantee that all nodes in a distributed system see the same data at the same time, or the rules governing when different nodes may see different versions of data. Different consistency levels provide different guarantees, trading off between consistency, availability, and performance.

💡 Key Insight: Perfect consistency (all nodes see same data instantly) is often impossible or too expensive. Most systems use weaker consistency models that are "good enough" for their use case.

# Core Concepts

# Strong Consistency

Definition: All nodes see the same data at the same time. After a write completes, all subsequent reads (from any node) return the updated value.

Characteristics:

• Synchronous replication
• All reads see latest write
• No stale data
• Higher latency (waits for all replicas)

Example: Financial transactions, inventory systems

# Eventual Consistency

Definition: System will become consistent over time if no new updates are made. Different nodes may temporarily see different data.

Characteristics:

• Asynchronous replication
• Stale reads possible
• Lower latency
• Higher availability

Example: DNS, social media feeds, user profiles

# Consistency Models

# 1. Strong Consistency

• Linearizability: All operations appear to execute atomically
• Sequential Consistency: Operations appear to execute in some sequential order
• Strict Serializability: Linearizability + transaction isolation

# 2. Weak Consistency Models

• Eventual Consistency: System becomes consistent eventually
• Causal Consistency: Causally related operations are ordered
• Session Consistency: Consistency within a user session
• Read Your Writes: User sees their own writes immediately

# Use Cases

# Strong Consistency

1. Financial Systems

   • Banking transactions
   • Payment processing
   • Stock trading
   • Why: Data accuracy critical

2. Inventory Management

   • Product stock levels
   • Reservation systems
   • Why: Prevent overselling

3. Critical Data

   • User authentication
   • Configuration data
   • Why: Consistency required

# Eventual Consistency

1. Social Media

   • User feeds (Twitter, Facebook)
   • Likes, comments
   • Why: High availability more important

2. DNS

   • Domain name resolution
   • Why: Global distribution, eventual consistency acceptable

3. User Profiles

   • Profile updates
   • Preferences
   • Why: Stale data acceptable for short periods

# Advantages & Disadvantages

# Strong Consistency Advantages

✅ Data Accuracy: Always see latest data
✅ Simpler Reasoning: Easier to reason about system state
✅ No Stale Data: Eliminates confusion from stale reads
✅ ACID Guarantees: Supports transactions

# Strong Consistency Disadvantages

❌ Higher Latency: Must wait for all replicas
❌ Lower Availability: System unavailable if replicas down
❌ Performance: Synchronous replication slower
❌ Scalability: Harder to scale horizontally

# Eventual Consistency Advantages

✅ High Availability: System remains available
✅ Lower Latency: Faster responses
✅ Better Performance: Asynchronous replication
✅ Scalability: Easier to scale horizontally

# Eventual Consistency Disadvantages

❌ Stale Data: May read outdated information
❌ Complex Reasoning: Harder to reason about state
❌ Application Logic: Must handle inconsistency
❌ User Confusion: Users may see inconsistent state

# Best Practices

# 1. Choose Right Consistency Level

• Strong: When data accuracy critical
• Eventual: When availability more important
• Session: For user-facing applications
• Causal: For systems with dependencies

# 2. Handle Stale Reads

• Use version numbers/timestamps
• Implement conflict resolution
• Show "last updated" timestamps
• Accept eventual consistency in UI

# 3. Monitor Consistency

• Track replication lag
• Monitor consistency violations
• Set up alerts for inconsistencies
• Measure consistency metrics

# Common Pitfalls

⚠️ Common Mistake: Using strong consistency everywhere.

Solution: Use eventual consistency when acceptable. Strong consistency has performance costs.

⚠️ Common Mistake: Not handling stale reads in application.

Solution: Design UI to handle eventual consistency. Show timestamps, handle conflicts.

# Interview Tips

🎯 Interview Focus: Understand trade-offs and when to use each level.

# Common Questions

• "Explain strong vs eventual consistency."
• "When would you use eventual consistency?"
• "How do you handle stale reads?"

# Related Topics

• CAP Theorem: Consistency vs availability trade-off
• Isolation Levels: Transaction isolation
• Priority Framework: Decision making

# Quick Reference Summary

Strong Consistency: All nodes see same data immediately. Use for financial systems, inventory.

Eventual Consistency: System becomes consistent over time. Use for social media, DNS, user profiles.

Key Trade-off: Consistency vs Availability. Choose based on requirements.

Next Topic: Isolation Levels →

Back to: Step 3 Overview | Main Index