Summary

In this chapter, we confronted and explored the major issues that stem from Cassandra's masterless, distributed, and replicated architecture. Interacting with Cassandra often feels indistinguishable from working with a single-node data store but, when working with any distributed database, we need to think about the tradeoff between consistency and availability. In some situations, we might be willing to read slightly out-of-date data for the sake of performance and failure tolerance; in others, we will tolerate a higher probability of a request failing in order to ensure that the data we're reading is fully up-to-date.

You learned that the partition key for a row determines not only its physical location in storage, but also which nodes within the cluster store copies of the row. This further motivates the practice of designing our table schemas such that most queries are looking for data grouped under a single partition key.

You discovered how, in a distributed database, deletion...