CAP Theorem – Algocraft System Design

🎮 What you can do

Pick system type: CA / CP / AP
Toggle Inject Partition to split the network
Click Send Write and Send Read to see the difference

👁 What to watch

CP nodes show 503 badges — refusing reads to stay consistent
AP nodes show a stale-data warning — staying available
Consistency and availability meters flip instantly on partition

System Type

Network Controls

Guarantees

Consistency 100%

Availability 100%

CA systems assume no network partition. Ideal for single-datacenter setups.

Real Systems

CP

🍃 MongoDB

🐘 ZooKeeper

🗄️ HBase

🔐 etcd

💎 BigTable

AP

🌿 Cassandra

⚡ DynamoDB

☁️ CouchDB

🛋️ Riak

📡 Voldemort

CA

🐬 MySQL

🐘 Postgres

🪶 SQLite

🦈 MariaDB

🌐 Oracle

Network State: No Partition

CA Mode

🖥️

Node A

Primary

✓ Synced

v=42

🖥️

Node C

Replica

✓ Synced

v=42

🖥️

Node B

Replica

✓ Synced

v=42

Select a system type and use the controls to explore CAP trade-offs. Inject a network partition to see how each system responds differently.

🔬

PACELC Extension

CAP only covers partition scenarios. PACELC extends it: "If Partitioned → choose A or C; Else (no partition) → choose Latency or Consistency." Even healthy systems trade-off: DynamoDB defaults to eventual consistency for lower latency, but can be configured for strong consistency at higher cost.

When to Use CP

Banking systems, inventory management, financial ledgers, distributed locks. Any domain where stale data = wrong data and returning an error is safer than returning outdated info.

When to Use AP

Social media feeds, DNS resolution, shopping carts, CDN caches. Systems where availability matters more than perfect consistency — users prefer slightly stale data over errors.

Interview Tip

PACELC extends CAP — even without partitions, you trade Latency vs Consistency. Always ask: "How often do partitions actually occur?" Then design around the realistic scenario.