As systems grow, failures become inevitable—nodes crash, networks partition, and replicas fall behind or become temporarily unavailable.
Building resilient distributed systems is therefore about making the right trade-offs.
The CAP Theorem provides a framework for understanding these trade-offs and guides architects in choosing which guarantees to prioritize when failures occur.
What is CAP Theorem?
CAP Theorem states that a distributed system can guarantee only two out of the three properties at the same time:Consistency (C) – Every read returns the most recent write, as if the system were a single machine.
Availability (A) – The system always returns a response, even if some nodes are down.
Partition Tolerance (P) – The system continues operating even when communication between nodes is lost or delayed.
In practice, Partition Tolerance is non-negotiable because network failures are inevitable.
This means designers must choose between strong consistency or high availability whenever a partition occurs.
Consistency vs Availability Under Network Partition
A network partition occurs when communication between groups of nodes is interrupted, causing a cluster to split into isolated parts.During such a failure, a distributed system must choose between Consistency and Availability.
1. Consistency over Availability (CP): The system rejects some reads or writes until a majority of replicas can communicate and agree on the latest state. This ensures that clients never see stale or conflicting data, but some requests may fail temporarily.
2. Availability over Consistency (AP): The system continues accepting reads and writes even when replicas cannot communicate. This keeps the application available, but different replicas may temporarily return different versions of the data until they synchronize.
Neither approach is universally better.
The right choice depends on the application's business requirements—whether data correctness or continuous availability is more important during network failures.
Example: Inventory vs Product Catalog
Inventory (CP Choice)
During checkout, when a customer purchases the last pair of shoes, the system cannot risk overselling simply to remain available.If a network partition prevents replicas from synchronizing, it is safer to reject or delay new orders until the latest inventory state can be confirmed.
For this reason, inventory services typically adopt CP guarantees, prioritizing Consistency and Partition Tolerance over Availability.
Product Catalog (AP Choice)
In contrast, when users are browsing products or searching the catalog, the system can tolerate slightly stale data.If the inventory for a shoe decreases from 10 to 8 but a distant replica still shows 10 for a few seconds, the browsing experience is largely unaffected.
As a result, product catalogs, search, recommendation engines, and customer reviews commonly adopt AP guarantees, prioritizing Availability and Partition Tolerance over strict Consistency.
During a network partition, these services continue serving requests even if some product information is temporarily out of date.
Payments (CP / Hybrid)
Payments are a hybrid scenario where availability is important, but correctness is critical.To prevent duplicate charges, inconsistent account balances, or lost settlements, payment systems typically use strongly consistent write paths, even if that means temporarily rejecting transactions during network partitions.
Many e-commerce platforms therefore treat payment processing similarly to inventory and adopt CP behavior for transactional writes.
Once a payment has been safely committed, downstream processes such as settlement, reporting, analytics, and notifications often rely on eventual consistency, providing a balance between correctness and scalability.
Conclusion
CAP is a business trade-off. Tools like Cassandra, MongoDB, DynamoDB, Spanner, PostgreSQL clusters all offer tunable consistency levels.The real decision is whether your business can tolerate stale reads or failed writes during network partition.
• For revenue-critical operations (checkout, inventory, payments), you choose Consistency first.
• For high-volume browsing experiences (catalog, search, analytics), you choose Availability first.
