The CAP theorem (Brewer, 2000) says that when a network Partition (P) splits a replicated cluster, a distributed database can guarantee either Consistency (C) or Availability (A), but not both at once. This simulator keeps N nodes storing one shared value. Toggling "Trigger partition" severs the links between two node groups, exactly like a torn network cable or a cross-region outage. Each incoming write picks a random reachable node and, in CP mode, is only accepted if that node's side of the split can reach a majority quorum — otherwise the write is rejected outright, sacrificing availability to guarantee every accepted value is the same everywhere. In AP mode every side keeps accepting writes locally no matter the split size, so both halves stay available but their stored values silently drift apart until the partition heals and a last-write-wins reconciliation pulls them back together.
quorum = floor(N / 2) + 1
CP: accept write ⇔ reachable_group.size ≥ quorum
AP: accept write always → divergence grows while split
- Mode (CP / AP) — which half of the CAP trade-off the cluster enforces once a partition is live.
- Trigger partition — splits the ring into two clusters with severed cross-links; press again to heal it and watch the sides reconcile.
- Nodes — cluster size. An odd count gives one side a majority quorum in CP mode; an even count means neither side reaches quorum and the whole cluster stops accepting writes during the split.
- Write rate — how often a client attempts a write to a random node, driving the accepted/rejected/diverged counters.
Real-world relevance: CP databases like HBase or MongoDB (majority reads) return errors during a partition rather than risk stale data; AP databases like Cassandra or DynamoDB always answer, accepting that concurrent partitions may return different values until a conflict-resolution pass — often last-write-wins or a CRDT merge — converges them again.