Chapter 2. Cassandra Architecture

This chapter aims to set you into a perspective where you will be able to see the evolution of the NoSQL paradigm. It will start with a discussion of common problems that an average developer faces when the application starts to scale up and software components cannot keep up with it. Then, we'll see what can be assumed as a thumb rule in the NoSQL world: the CAP theorem that says to choose any two out of consistency, availability, and partition-tolerance. As we discuss this further, we will realize how much more important it is to serve the customers (availability), than to be correct (consistency) all the time. However, we cannot afford to be wrong (inconsistent) for a long time. The customers wouldn't like to see that the items are in stock, but that the checkout is failing. Cassandra comes into picture with its tunable consistency.

We will take a quick peep into all the actions that go on when a read or mutate happens. This leaves us with lots of fancy terms. Next, we will move on to see these terms in full glory with explanation as we discuss various parts of the Cassandra design. You will be amazed to see how close yet how far Cassandra is when compared with its precursors and inspiration databases, such as Google's BigTable and Amazon's Dynamo. We will meet with some of the modern and efficient data structures, such as bloom filters and Merkle trees, and algorithms, such as gossip protocol, phi accrual error detectors, and log-structured merge trees. Some of these discussions will help you rationalize the performance and constraints of Cassandra.