CAP: consistency and availability during partitions

01Ask what happens when replicas cannot talk

East and West keep copies of a shared number, called x. Both begin at zero. Their network link breaks, but clients can still reach either region.

1. One client asks East to set x to 1.
2. East saves the change and reports success.
3. Only after receiving that success, another client asks West to read x.
4. West still has zero and cannot communicate with East. What should it return?

West cannot learn whether East accepted the write until the required communication recovers. This example exposes the CAP limit. CAP names consistency, availability, and partition tolerance, with specific meanings:

• A network partition prevents required messages from getting between parts of the system. It does not require either region’s process to stop.
• Consistency in the usual CAP formulation means linearizability: operations on the same modeled data appear to occur one at a time in an order that respects real completion times. A read starting after a successful write must reflect that write or a later valid change.
• CAP availability requires every request received by a non-failing node eventually to complete the requested operation with an appropriate result. A quick refusal is a failure response, not completion of that write or read.

During a partition, the same replicated read/write data cannot guarantee both of those last two promises at every non-failing node. Eventual agreement between copies, valid database rows, monthly success percentages, and practical response-time targets remain useful ideas, but they are different definitions.

02Work the two-region trace

Apply each possible action to West’s later read. Keep East’s successful write earlier than that read; otherwise this example would not test the same promise.

More replicas can allow useful service on part of the system:

1. Suppose a protocol needs more than half the replicas to establish authority.
2. The side containing that majority may continue under the protocol’s full rules.
3. A smaller isolated side cannot meet the same requirement and waits or refuses.
4. Requests on that smaller side still fail to complete, even when its processes are running. This is therefore not universal CAP availability.

Avoid “choose any two” as a design procedure:

• A deployed network can lose communication regardless of the database label. The design must say what happens then.
• When required communication works, a supported protocol can often provide both useful availability and strong consistency. CAP does not ban that normal behavior.
• CAP states an impossible combination of guarantees. An implementation can still do worse by losing availability without providing the intended consistency.

Draw the failed communication and one operation timeline before applying a label.

03Choose behavior per operation and recover

A marketplace need not use the same failure policy for every operation. Follow the consequence for each one:

• A seat confirmation must establish that no other purchase owns the seat. If an isolated region cannot establish exclusive ownership, it must wait or fail rather than confirm twice.
• A public event description can come from an older local copy if the product permits that age.
• A view counter may accept local increments if the service safely saves them and can combine them without losing or counting an increment twice.

Make the counter’s duplicate handling concrete:

1. Assign each intended increment a stable identifier; a retry retains that same identifier.
2. Save accepted identifiers in the region before reporting success under the chosen durability policy.
3. After communication returns, combine the retained identifier sets from the regions.
4. Count each distinct identifier once. Do not add the same retried increment again.

This simple exercise explains the required behavior; a production implementation may use a more compact representation. A timestamp alone does not add every increment correctly.

For conflicting edits, name what is lost. A last-write-wins rule keeps the value with the winning timestamp. Two edits of the same profile field can converge to one value while discarding the other edit; clock disagreements and ties need rules too.

For every local-completion policy, answer these recovery questions:

1. Which updates were confirmed, and where are they retained?
2. How are duplicates recognized and conflicting versions compared?
3. Who resolves incompatible changes, and what reversal or compensation can the user see?
4. Which permission checks remain required throughout the outage?

Useful reduced service is a product choice with explicit guarantees. A counter merge does not solve exclusive seat ownership.