System Design Series

CAP Theorem Simulator

Start learning why Consistency and Availability are at odds when your network breaks.

CAP Theorem Simulator

Visualize Consistency vs. Availability

System Mode:

Click lines to cut network

v: 0

Primary (Writer)

WRITER

v: 0

Replica 1

v: 0

Replica 2

Client Actions

Writes are sent to Node A. In AP mode, A accepts immediately.

System Console

System ready. Waiting for events...

Quick Guide: CAP Theorem

Understanding the basics in 30 seconds

How It Works

C = Consistency: All nodes see same data
A = Availability: Every request gets response
P = Partition Tolerance: Works despite network splits
During partition: Choose C or A, not both
No partition: Can have both C and A

Key Benefits

Understand distributed system trade-offs
Make informed architecture decisions
CP: Strong consistency (banking)
AP: High availability (social media)
Design for your specific use case

Real-World Uses

CP: MongoDB, HBase, Redis Cluster
AP: Cassandra, DynamoDB, CouchDB
Banking: Consistency is critical
E-commerce: Availability preferred
DNS: Eventually consistent

Interactive CAP Theorem Simulator: Consistency vs. Availability

Understand why Distributed Architectures must choose between Strong Consistency and High Availability during network partitions.

The Core Trade-off

The CAP Theorem (Brewer's Theorem) states that a distributed data store can only provide two of the following three guarantees simultaneously:

Consistency (C): Every read receives the most recent write or an error.
Availability (A): Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
Partition Tolerance (P): The system continues to operate despite an arbitrary number of messages being dropped or delayed by the network between nodes.

How the Simulator Works

In a real-world Distributed Database, network partitions (P) are inevitable. Therefore, you must choose between C and A:

CP Mode (Consistency Preferred)

Examples: HBase, MongoDB, Redis (default).

If the system detects a partition (e.g., Node A cannot reach Node B), it stops accepting writes to preserve data accuracy. It sacrifices Availability to ensure no user sees stale data.

AP Mode (Availability Preferred)

Examples: Cassandra, DynamoDB, CouchDB.

The system always accepts writes, even if nodes are disconnected. Node A will update its local data, but B will remain old. This creates Eventual Consistency, where nodes sync up only after the network heals.