CAP Theorem: ATM Simulation

The CAP theorem states that a distributed system can provide at most two of three guarantees simultaneously: Consistency, Availability, and Partition tolerance. Since network partitions are unavoidable in distributed systems, the practical choice is between consistency and availability during a partition.

This simulation uses an ATM network with a shared account to let you explore the trade-off hands-on. Withdraw money, create partitions, and see what happens when the network heals.

How It Works

1. Withdraw money from any ATM — the backend confirms and syncs the balance to all connected ATMs
2. Click a connection line to simulate a network partition isolating that ATM
3. Choose a mode — Consistency (reject withdrawals at partitioned ATMs) or Availability (allow offline withdrawals up to a cap)
4. Attempt more withdrawals at both connected and partitioned ATMs to see the behavior
5. Heal the partition to trigger reconciliation and see if overdrafts occurred

Simulation

Key Takeaways

• The CAP theorem is not about choosing two of three properties in general — it is about what happens during a partition
• Network partitions are not a choice; they will happen in any distributed system
• The real decision is: when a partition occurs, do you prefer consistency or availability?
• Many real systems choose different strategies for different operations within the same system
• The trade-off is often a spectrum, not a binary choice — techniques like timeouts, quorums, and bounded staleness provide nuance
• Offline caps limit risk in AP mode — a common pattern in real ATM networks

Further Reading

• Brewer's original conjecture (2000) and Gilbert & Lynch's proof (2002)
• The "CAP Twelve Years Later" article by Eric Brewer (2012) — clarifies common misconceptions
• PACELC theorem — extends CAP to consider latency vs. consistency even when there is no partition

Decision Angle

In real systems, CAP trade-offs are architectural decisions. Teams should record when they choose consistency over availability, accept bounded staleness, allow offline operations with caps, or adopt specific reconciliation strategies. These are exactly the kinds of decisions that benefit from an Architecture Decision Record - they involve trade-offs, affect system behavior under failure, and are easy to forget once the system is running.