Partition tolerance

Action history

Compare two explicit request policies

This experiment contains two sites, A and B, each with its own register and two-component causal context. Local acceptance allows reads and writes on either reachable site while the connection between them is broken. Require both rejects reads and writes during that split. These are concrete policies in this teaching fixture, not complete implementations of every system described as AP or CP. Both sites themselves remain alive; only their inter-site connection fails. Client site chooses which local state a request reaches, so the experiment never selects a destination randomly behind your back.

Control the request and the link

Policy chooses local acceptance or require both. Changing it deliberately starts an empty experiment, keeping histories from different policies separate. Client site chooses A or B. Value to write accepts an integer from zero through nine hundred ninety-nine. Write selected site records a new value and increments only that writer component after incorporating the context actually available to it. Read selected site reports stored versions without creating a write. Disconnect link prevents cross-site exchange; Restore link makes exchange possible again but does not itself move any versions. Reconcile sites exchanges available state only while connected. Reset experiment clears values, history and the split while retaining the selected policy.

Create two concurrent versions

Choose local acceptance and disconnect the link. Write ten at site A. Then select site B and write twenty. A has context [1,0] and B has [0,1]; neither writer knows about the other write. Reading either site returns its own local value. No hidden global counter ranks the writes by the order of your clicks. Restore the link and inspect both sites before reconciliation: the distinct values remain. Now reconcile. Both sites retain the two concurrent versions, because neither context dominates the other. The page reports a conflict rather than quietly discarding one value.

Resolve with an informed new write

After reconciling the two versions, select A and write thirty. Both available contexts are incorporated, then A increments its component to [2,1]. The new version causally follows both earlier versions and replaces them at both sites. This resolving write expresses your chosen value; it is not an automatically discovered business-correct answer. A connected write first exchanges both contexts in this fixture, so it also resolves known concurrent versions. If you need to inspect the conflict before choosing a value, use Reconcile sites and Read selected site first. Repeating reconciliation without a new write does not change the result.

Contrast unavailable requests

Reset using Require both, write seven while connected, and disconnect. Read or write from either site now fails. The last-action report states that both sites are required, and stored values remain unchanged. Restoring the connection permits requests again. With Local acceptance, the same split allows each side to continue independently, but a read from B can miss a write accepted at A. This experiment makes the rejected-request and divergent-state outcomes visible; it does not reduce the CAP theorem to an unrestricted menu of two desirable properties or establish production linearizability.

Understand the displayed evidence

Each site panel lists its accumulated context and every currently retained version, including writer and value. The connection diagram shows only link state; the last-action report and history show actual request effects. No animation delay is needed for this direct-manipulation register: each click applies one explicit action. The forty-action limit requires a reset rather than erasing older evidence. The model assumes fixed membership, reliable local storage, immediate exchange when requested on a healthy link, and no client context beyond the state observed by the selected site. It has no physical clocks, geographic latency, multi-node quorums, automatic anti-entropy, network packet queue or crash recovery. A causal merge retains non-dominated versions; application conflict resolution remains a separate choice.