CAP Theorem Explained

What is CAP Theorem?

The CAP theorem states that a distributed data store can only guarantee two of the following three properties:

• Consistency: Every read receives the most recent write
• Availability: Every request receives a response (not an error)
• Partition Tolerance: The system continues to operate despite network partitions

Why Does This Matter?

In any distributed system (which includes most cloud services), network partitions will happen. This means you're really choosing between:

• CP Systems: Consistent but may be unavailable during partitions
• AP Systems: Available but may return stale data during partitions

Visual Representation

        Consistency (C)
             /\
            /  \
           /    \
          / CP   \
         /________\
        /    |     \
       /     |      \
      /  CA  |  AP   \
     /  (not |        \
    /  really\         \
   /  possible)\        \
  ──────────────────────
Availability (A)    Partition
                   Tolerance (P)

In distributed systems, P is mandatory.
You really choose between C and A.

Real-World Examples

CP Systems (Consistency + Partition Tolerance):

• MongoDB (in certain configurations)
• HBase
• Redis Cluster
• Zookeeper

Use case: Financial transactions where incorrect data is worse than no data.

Behavior during partition: System may refuse to respond rather than return stale data.

AP Systems (Availability + Partition Tolerance):

• Cassandra
• DynamoDB (eventual consistency mode)
• CouchDB
• Riak

Use case: Social media feeds where showing slightly stale data is acceptable.

Behavior during partition: System responds with potentially stale data rather than failing.

Consistency Levels Explained

Modern databases offer tunable consistency:

• Strong: Read always sees latest write → Financial transactions
• Bounded Staleness: Reads lag by at most X seconds → Leaderboards, analytics
• Session: Consistent within a user session → Shopping carts
• Eventual: Reads may be stale temporarily → Social feeds, likes

Azure & AWS Services Through CAP Lens

Azure Cosmos DB is unique because it offers tunable consistency. You can choose from five consistency levels:

1. Strong (CP behavior)
2. Bounded Staleness
3. Session
4. Consistent Prefix
5. Eventual (AP behavior)

Cosmos DB Consistency Spectrum:
Strong ←————————————————————→ Eventual
Higher latency            Lower latency
Higher cost               Lower cost
CP behavior               AP behavior

Amazon DynamoDB:

• Strongly consistent reads: CP behavior
• Eventually consistent reads: AP behavior (default, faster, cheaper)

Google Cloud Spanner:

• Globally distributed with strong consistency
• Uses TrueTime (atomic clocks) for synchronization
• Achieves CP with high availability

PACELC: Beyond CAP

CAP only describes behavior during partitions. PACELC extends this:

Partition → choose Availability or Consistency
Else (no partition) → choose Latency or Consistency

System Examples:
┌────────────┬─────────────┬─────────────┐
│ System     │ If Partition│ Else        │
├────────────┼─────────────┼─────────────┤
│ DynamoDB   │ PA          │ EL          │
│ Cassandra  │ PA          │ EL          │
│ MongoDB    │ PC          │ EC          │
│ Spanner    │ PC          │ EC          │
└────────────┴─────────────┴─────────────┘

Practical Design Patterns

Pattern 1: Different Consistency for Different Data

User Profile Data → Strong Consistency
Activity Feed → Eventual Consistency
Shopping Cart → Session Consistency
Analytics → Eventual Consistency

Pattern 2: Read Your Own Writes

• After writing, read from primary
• After a delay, read from replicas
• Provides good user experience without strong consistency everywhere

Pattern 3: Conflict Resolution

• Last-write-wins (simple but can lose data)
• Vector clocks (preserves all writes)
• Application-level merge (custom logic)

Beyond the Exam

The exam might ask which properties a system provides. In real architecture:

1. Understand your data: Not all data needs strong consistency
2. Design for partition: Assume network failures will happen
3. Mix and match: Use different consistency levels for different data types
4. Monitor replication lag: Know how far behind replicas are

Common Misconceptions

1. "CA systems exist": In practice, you can't have CA because partitions happen
2. "You must pick exactly two": Modern systems offer tunable trade-offs
3. "Strong consistency = slow": It's about availability during partitions, not normal performance
4. "Eventual consistency = data loss": Data is not lost, just temporarily inconsistent

Exam Tips

Questions often ask:

• Which two guarantees does [Service X] provide?
• What happens to a CP system during a network partition?
• Which consistency level should be used for [Scenario]?

Remember:

• Cosmos DB lets you choose (tunable)
• DynamoDB defaults to eventual, offers strong option
• Financial data usually needs strong consistency
• Social/analytics data can use eventual consistency

Key Takeaway

CAP theorem helps you reason about trade-offs in distributed systems. In cloud certifications, know which services offer which guarantees. In real projects, choose consistency levels based on your specific requirements.