NoSQL concepts - Making Sense of NoSQL - page 32

If you have… then you get…

Figure 2.11 The CAP theorem shows
that you can have both consistency
and availability if you're only using a
single processor. If you're using many
processors, you can chose between
consistency and availability depending
on the transaction type, user,
estimated downtime, or other factors.

A single processor or
many processors on a
working network

Consistency AND availability

Each transaction can select between
consistency OR availability depending
on the context

Many processors and
network failures

The rules about when the CAP theorem applies are summarized in figure 2.11.
Tools like the CAP theorem can help guide database selection discussions within an
organization and prioritize what properties (consistency, availability, and scalability)
are most important. If high consistency and update availability are simultaneously
required, then a faster single processor might be your best choice. If you need the
scale-out benefits that distributed systems offer, then you can make decisions about
your need for update availability versus read consistency for each transaction type.
Whichever option you choose, the CAP theorem provides you with a formal pro-
cess that can help you weigh the pros and cons of each SQL or NoSQL system, and in
the end you'll make an informed decision.

2.8 Apply your knowledge

Sally has been assigned to help a team design a system to manage loyalty gift cards,
which are similar to bank accounts. Card holders can add value to a card (deposit),
make a purchase (withdrawal), and verify the card's balance. Gift card data will be par-
titioned and replicated to two data centers, one in the U . S . and one in Europe. People
who live in the U . S . will have their primary partition in the U . S . data center and people
in Europe will have their primary partition in Europe.
The data line between the two data centers has been known to fail for short peri-
ods of time, typically around 10-20 minutes each year. Sally knows this is an example of
a split partition and that it'll test the system's partition tolerance. The team needs to
decide whether all three operations (deposit, withdraw, and balance) must continue
when the data line is down.
The team decides that deposits should continue to work even if the data line is
down, since a record of the deposit can update both sites later when the connection is
restored. Sally mentions that split partitions may generate inconsistent read results if
one site can't update the other site with new balance information. But the team
decides that bank balance requests that occur when the link is down should still
return the last balance known to the local partition.
For purchase transactions, the team decides that the transaction should go through
during a link failure as long as the user is connecting to the primary partition. To limit
risk, withdrawals to the replicated partition will only work if the transaction is under a
specific amount, such as $100. Reports will be used to see how often multiple withdraw-
als on partitions generate a negative balance during network outages.