# Consistency vs Availability

Quick Reference: Push vs Pull | Step 3: CAP Theorem

# Quick Reference

Consistency: All nodes see same data

Availability: System remains operational

Trade-off: In distributed systems, prioritize one during partitions

# Clear Definition

Consistency vs Availability is the fundamental CAP theorem trade-off. During network partitions, you must choose consistency (CP) or availability (AP) based on your system's requirements. This is one of the most critical decisions in distributed system design.

💡 Key Insight: Financial systems prioritize consistency, social media prioritizes availability. Most production systems use a hybrid approach with different consistency levels for different data types.

# Core Concepts

# CP Systems (Consistency + Partition Tolerance)

Characteristics:

• Prioritize data consistency above all else
• May reject requests during network partitions
• Ensure all nodes have the same view of data
• Strong consistency guarantees

Examples:

• MongoDB (with replica sets): Ensures reads from primary
• HBase: Strong consistency for distributed storage
• ZooKeeper: Used for coordination with strong consistency
• Financial systems: Banking, payment processing

When to Use:

• Financial transactions (money must be consistent)
• Inventory systems (stock counts must be accurate)
• Configuration management
• Leader election systems

Trade-offs:

• ✅ Strong data integrity
• ✅ No stale data
• ❌ May be unavailable during partitions
• ❌ Higher latency (waiting for consensus)

# AP Systems (Availability + Partition Tolerance)

Characteristics:

• Prioritize system availability
• Continue serving requests even during partitions
• May serve stale or inconsistent data
• Eventual consistency model

Examples:

• Cassandra: Eventually consistent, highly available
• DynamoDB: High availability with eventual consistency
• CouchDB: Multi-master replication
• Social media feeds: Twitter, Facebook

When to Use:

• User-facing applications (better to show stale data than nothing)
• Social media feeds
• Content delivery systems
• Analytics and logging

Trade-offs:

• ✅ Always available
• ✅ Lower latency
• ✅ Better user experience during failures
• ❌ May serve stale data
• ❌ Eventual consistency complexity

# Decision Framework

# Step 1: Identify Data Criticality

High Criticality (Choose CP):

• Financial transactions
• User account balances
• Inventory counts
• Medical records
• Legal documents

Low Criticality (Choose AP):

• User profiles (can be slightly stale)
• Social media feeds
• Recommendations
• Analytics data
• Cached content

# Step 2: Analyze Failure Scenarios

Ask yourself:

• What happens if data is inconsistent?
• What happens if system is unavailable?
• Can users tolerate stale data?
• Is data integrity more important than uptime?

# Step 3: Consider Hybrid Approaches

Most real-world systems use hybrid consistency models:

┌─────────────────────────────────────┐
│  System Architecture                │
├─────────────────────────────────────┤
│  CP Layer:                          │
│  - Financial transactions           │
│  - User authentication              │
│  - Critical inventory                │
├─────────────────────────────────────┤
│  AP Layer:                          │
│  - User profiles                    │
│  - Social feeds                     │
│  - Recommendations                  │
│  - Analytics                        │
└─────────────────────────────────────┘

# Real-World Examples

# Example 1: E-commerce Platform

CP Components:

• Payment processing (must be consistent)
• Inventory management (prevent overselling)
• Order processing (ensure order integrity)

AP Components:

• Product catalog (can be slightly stale)
• User recommendations (eventual consistency OK)
• Search index (can be eventually consistent)

# Example 2: Social Media Platform

CP Components:

• User authentication
• Account settings
• Privacy controls

AP Components:

• News feed (eventual consistency acceptable)
• Likes and reactions
• Comments (can be eventually consistent)
• Trending topics

# Example 3: Banking System

CP Components:

• Account balances (must be consistent)
• Transaction history
• Transfer operations

AP Components:

• Transaction notifications (can be delayed)
• Analytics dashboards
• Marketing recommendations

# Consistency Levels (Beyond CP/AP)

# Strong Consistency

• All reads see latest write
• Linearizability guarantees
• Use for: Financial data, critical operations

# Eventual Consistency

• System will become consistent eventually
• No guarantees on when
• Use for: Social feeds, recommendations

# Weak Consistency

• No guarantees on consistency
• Best effort
• Use for: Analytics, logging

# Causal Consistency

• Preserves cause-effect relationships
• Stronger than eventual, weaker than strong
• Use for: Chat applications, collaborative editing

# Best Practices

# 1. Understand Your Requirements

• Question: What happens if data is inconsistent?
• Question: What happens if system is down?
• Question: Can users tolerate stale data?

# 2. Use Hybrid Approaches

• Different consistency for different data types
• CP for critical data, AP for non-critical
• Most production systems use this approach

# 3. Implement Monitoring

• Track consistency metrics
• Monitor availability metrics
• Alert on consistency violations
• Track partition events

# 4. Design for Failure

• Plan for network partitions
• Implement conflict resolution
• Use version vectors for conflict detection
• Design idempotent operations

# 5. Consider Read/Write Patterns

• Read-heavy: Can tolerate eventual consistency
• Write-heavy: May need stronger consistency
• Mixed: Use different consistency for reads vs writes

# Common Patterns

# Pattern 1: Read Your Writes

• After writing, ensure subsequent reads see the write
• Implement session consistency
• Use: User profiles, settings

# Pattern 2: Monotonic Reads

• Once a read sees a value, future reads won't see older values
• Prevents going "backward in time"
• Use: Social feeds, timelines

# Pattern 3: Consistent Prefix

• Reads see writes in order
• Preserves causality
• Use: Chat applications, comments

# Quick Reference Summary

Consistency: All nodes see same data. Critical for financial systems, inventory, transactions.

Availability: System stays operational. Critical for user-facing apps, social media, content delivery.

Key Decision Factors:

• Data criticality
• User tolerance for stale data
• Failure impact
• Read/write patterns

Best Practice: Use hybrid approach - CP for critical data, AP for non-critical data.

Remember: The CAP theorem is about choosing during partitions. In normal operation, you can often have both consistency and availability.

Previous Topic: Push vs Pull ←

Next Topic: SQL vs NoSQL →

Back to: Step 11 Overview | Main Index