Database Reference
In-Depth Information
The significance of the CAP theorem
Once you decide to scale up, the first thing that comes to mind is vertical scaling, which
means using beefier servers with a bigger RAM, more powerful processor(s), and bigger
disks. For further scaling, you need to go horizontal. This means adding more servers.
Once your system becomes distributed, the CAP theorem starts to play, which means, in a
distributed system, you can choose only two out of consistency, availability, and partition-
tolerance. So, let's see how choosing two out of the three options affects the system behavi-
or as follows:
•
CA system
: In this system, you drop partition-tolerance for consistency and avail-
ability. This happens when you put everything related to a transaction on one ma-
chine or a system that fails like an atomic unit, like a rack. This system will have
serious problems in scaling.
•
CP system
: The opposite of a CA system is a CP system. In a CP system, availab-
ility is sacrificed for consistency and partition-tolerance. What does this mean? If
the system is available to serve the requests, data will be consistent. In an event of
a node failure, some data will not be available. A sharded database is an example
of such a system.
•
AP system
: An available and partition-tolerant system is like an always-on system
that is at risk of producing conflicting results in an event of network partition. This
is good for user experience, your application stays available, and inconsistency in
rare events may be alright for some use cases. In the topic example, it may not be
such a bad idea to back order a few unfortunate customers due to inconsistency of
the system than having a lot of users return without making any purchases because
of the system's poor availability.
•
Eventual consistent (also known as BASE system)
: The AP system makes more
sense when viewed from an uptime perspective—it's simple and provides a good
user experience. But, an inconsistent system is not good for anything, certainly not
good for business. It may be acceptable that one customer for the topic
Nineteen
Eighty-Four
gets a back order. But if it happens more often, the users would be re-
luctant to use the service. It will be great if the system could fix itself (read: repair)
as soon as the first inconsistency is observed; or, maybe there are processes dedic-
ated to fixing the inconsistency of a system when a partition failure is fixed or a
dead node comes back to life. Such systems are called eventual consistent systems.
The following figure shows the life of an eventual consistent system:
