CAP Theorem: The Practical Meaning

I do not use CAP as a slogan. I use it as a production question: when the network splits, should this path keep accepting work or protect one version of truth?

The tradeoff appears during the partition

I use this section to force the failure case into the conversation, not just the clean path.

Before a partition, a system can be both available and consistent enough for its design. The tension appears when messages cannot cross a network boundary. At that point, the system needs a rule that operators and product teams understand.

Checkout example

This example is useful because it shows who owns the work and what breaks when the happy path disappears.

Two regions both accept a balance transfer while the link between regions is down. If both regions can write independently, reconciliation may find that the account spent the same money twice.

Partition handling code

I use the code here to show the decision boundary, not just syntax.

During a partition, make the risky write rule explicit:

Response handle(Request request, boolean partitioned) {
  if (partitioned && request.isRiskyWrite()) {
    return Response.reject("Write paused until replicas agree");
  }
  return request.isRead() ? serveFromLocalReplica(request) : commit(request);
}

The branch makes the CAP tradeoff explicit: reads can continue locally during a partition, but risky writes stop until replicas can agree again.

The tradeoff to name

• Name which data must stay strongly consistent.
• Name which workflows can accept delayed convergence.
• Document the user visible behavior during a partition.

Next distributed systems reads

• Microservices Are Not the Default Answer
• Real Time APIs or Events: Choose by the Shape of the Work
• Distributed Computing Jargon: An A to Z Glossary