CAP is a reminder about trade-offs in a distributed system. When a network partition happens, you cannot guarantee both:
- Consistency: every read sees the latest agreed value.
- Availability: every request gets a response.
Partition tolerance means the system keeps operating despite messages being delayed or lost between machines. In practice, partitions are not optional, so the choice is usually consistency or availability during that failure.
Imagine two replicas, A and B, storing a user’s balance. Normally they sync. Then the link between them breaks. A receives a request to subtract $10, while B receives a request to add $5. If both replicas accept writes, they stay available but now disagree: that is the availability side of the trade-off. If they refuse writes until they can coordinate again, they preserve consistency but sacrifice availability.
The useful lesson for a side project is not “CAP means pick two forever.” It is to decide what happens during a partition. For a shopping cart, accepting a temporary conflict may be fine. For a bank balance, rejecting the request is safer.
Top comments (0)