The CAP Theorem Trade-Off

In a distributed system, like the ones based on a microservices architecture, there are three guarantees that can be traded-off against each other when it comes to data stores: consistency, availability, and partition tolerance.

The CAP theorem — also called Brewer’s theorem — states that only two out of these three guarantees can be maintained when the system is in a failure mode, as indeed, no distributed system is safe from network failures and network partitioning must be tolerated, as for when it happens, it must be decided whether to ensure one of consistency or availability.

Guarantees Definition

Consistency — different from ACID transactions’ consistency where it’s about maintaining data constraints — means that every read operation receives the value of the most recent write operation or an error.

Availability means every read operation receives a valid response that is not an error, without the guarantee that it contains the value of the most recent write operation.

Partition tolerance means that the system continues to operate despite an arbitrary number of messages being dropped or delayed by the network between nodes.

Consistency vs. Availability

Sacrificing Consistency

Sacrificing consistency means that we decide to let our service process incoming requests, keeping it therefor available despite the network partitioning, while taking the risk of serving potentially stale data.

Which in turn implies that the longer the partition lasts while accepting writes, the more difficult this resynchronization will become.

Such system is designated as an AP system.

Sacrificing Availability

On the other hand, sacrificing availability means that to keep consistency, each database node must be able to know that the copy of the data it owns is the same as in the other nodes.

In the context of a partition when nodes are unable to coordinate, the only option is then to refuse to respond to the request by sending an error message instead.

Such system is designated as a CP system.

Which is best?

Now that I’ve presented to you the two possible system trade-offs, the obvious question remains: which of these solutions is best? And the simple answer is: it depends on the business impact it will have.

Imagine that you are developing a PHV app like Uber where customers can track in real-time their chauffeur’s location and the ETA to their pickup spot.

Would it cause for customers to cancel their ride if the chauffeur’s real-time location was out of date by a few hundred meters or if the ETA to the pickup spot was actually wrong by a couple of minutes?

If the answer is no, then trading consistency for availability might be the right answer as customers would rather have an approximate information rather than no information at all.

Imagine now that a chauffeur accepted the ride and is driving to the pickup spot.

Would it be a problem if the pickup address was actually the last know address from a previous ride and not the actual one the customer is waiting at?

If the answer is yes, then trading availability for consistency might be the right answer as sending a driver to a wrong address would cause the customer to cancel the ride and the driver not to trust your platform.