A customer buys the last available seat through one server while another customer requests that same seat through a second server. If the servers can exchange information promptly, coordination may prevent a double booking. If communication fails between them, each faces an epistemic difficulty: the absence of a message does not reveal whether the other server has sold the seat, crashed, or merely become unreachable. The problem is not solved by making either server more intelligent. Each lacks information whose absence cannot always be distinguished from delay within the system's stated assumptions.
Distributed computing turns this apparently mundane uncertainty into a question about guarantees. Strong consistency, in the relevant sense of linearizability, requires operations to behave as though they occurred in a single order respecting their real-time completion. Availability, in the formal setting of the CAP result, requires every request to a non-failing node eventually to receive a valid response. A network partition prevents some nodes from communicating. Under such a partition, the system cannot guarantee both properties for all permitted executions. The impossibility concerns a specified model and definitions, not every ordinary meaning of reliability.
The popular instruction to 'choose any two' can consequently mislead. Network partitions are not usually a feature an operator can abolish by declining to select them. Once communication is disrupted, the design must decide which operations can proceed and which guarantees it will preserve. Nor does consistency here merely mean that stored values look sensible, while availability merely means a website is usually online. Translating technical results into ordinary language without retaining their definitions produces slogans that are easy to repeat and difficult to apply. The apparent simplicity comes from removing the conditions that make the claim true.
Return to the seat. A system that prioritises a single authoritative allocation can require contact with the appropriate coordinating nodes before confirming a purchase. During a partition, some customers may receive no successful confirmation. This refusal is not necessarily evidence of poor engineering. It may be the visible cost of preventing incompatible commitments. Alternatively, the system could accept requests locally and reconcile conflicts later. That may preserve responsiveness, but a subsequent cancellation reveals that the earlier confirmation did not possess the finality users reasonably inferred from it. The interface has then made a promise stronger than the underlying operation.
Not every application requires the same promise. Two disconnected devices adding different items to a personal reading list can often combine their changes later without serious conflict. Two withdrawals against a strict spending limit may not admit the same treatment. The relevant distinction concerns the invariants that must remain true: no duplicate sale, no negative stock, or perhaps only the preservation of all additions. A universal preference for either immediate agreement or uninterrupted response ignores these differences. Engineering judgement begins by asking what must never happen, what may temporarily differ, and what can be repaired without violating the service's purpose.
Eventual consistency describes a weaker promise under which replicas converge if updates cease and the required communication and reconciliation occur. The word eventual should not be read as a guarantee that every practical consequence of temporary divergence disappears. A user may already have acted on an outdated value. Convergence of records does not reverse a missed appointment or restore trust after contradictory confirmations. The technical state can become consistent while the social consequences remain asymmetric. This is why conflict resolution is partly a question of semantics: what do the operations mean, and which losses can the application legitimately impose?
Redundancy complicates the picture further. Replication can improve resilience by ensuring that one failed machine does not destroy the service. Yet each additional copy introduces a coordination problem if all copies must support tightly ordered updates. Redundancy is therefore not equivalent to independent reliability added without cost. Its benefit depends on the failure model and the protocol connecting the replicas. Several machines sharing a power source may fail together; geographically dispersed machines may avoid that failure while encountering larger communication delays. A design can redistribute vulnerability without eliminating it, making one failure less likely and another more consequential.
The distinction between safety and liveness clarifies what might otherwise appear contradictory. Safety requires that certain bad events never occur; liveness requires that useful progress eventually occur. A system that refuses every transaction may preserve a narrow safety condition while being practically useless. A system that approves everything may make progress while violating essential constraints. The objective is not to choose a virtue and ignore the other. It is to specify the circumstances under which each can be guaranteed and to ensure that degraded behaviour remains intelligible. Hidden degradation is often more damaging than an explicit, limited refusal.
These ideas resist a fashionable analogy with human consensus. Computers agreeing on a value do not thereby establish that the value is true or just. A protocol can coordinate replicas around incorrect input, and a perfectly ordered ledger can record an unfair transaction. Technical consensus concerns agreement under specified operational assumptions; political legitimacy concerns additional questions of participation, authority, and contestability. Treating the former as a substitute for the latter imports prestige across a conceptual boundary. The precision of a distributed protocol cannot resolve a moral dispute that its specification never attempted to represent.
Even within computing, a theorem's impossibility should not become a blanket excuse for avoidable failure. Systems can limit the scope of coordination, exploit operations that commute, improve failure detection under practical assumptions, or give users carefully bounded alternatives. None of these strategies invalidates the theorem. They change the guarantees, the workload, or the assumptions to obtain a useful design. The distinction is essential: an impossibility result identifies the limits of a demand, while engineering explores the feasible arrangements around those limits. Invoking impossibility too broadly can conceal a lack of imagination about the actual requirements.
For users, the central issue is whether the service communicates what its responses mean. 'Request received', 'provisionally reserved', and 'purchase confirmed' describe different states. Collapsing them into a reassuring animation may improve perceived speed while transferring uncertainty to the customer. Clear design makes some of the system's contingency visible without forcing users to understand its internals. The goal is not a lecture on network partitions at checkout. It is a promise whose ordinary interpretation matches the guarantee the system can maintain, especially when conditions are least favourable to maintaining it.
The database that sometimes refuses is thus a useful corrective to the assumption that convenience and reliability always improve together. Refusal can express fidelity to a commitment that immediate compliance would break. But it earns that interpretation only when the commitment is necessary, the failure mode understood, and alternatives considered. A distributed system cannot make missing information disappear by speaking confidently. Its sophistication lies in knowing when it can act despite uncertainty, when it must wait, and how to prevent the unavoidable limits of coordination from becoming avoidable confusion for the people relying on it.
Source notes
- [2] Gilbert and Lynch, Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services (2002). Author bibliography; background to the CAP result. Open primary source