In Cassandra, a client can batch multiple statements, which may or may not be related to be executed as a single statement. Earlier, we got a first look at how to use batches in Cassandra. Here, we will dig a bit deeper into the different types of batches and how batches have evolved over time to accommodate more nuanced features, such as atomic batching, batches with custom timestamps, and so on.
Prior to Cassandra 1.2, batches were somewhat resilient. If an update within a batch failed, the coordinator would just hint that particular update. This ensured that all the updates within a batch were eventually committed assuming the coordinator node doesn't go down in between. In the case of the failure scenario where the coordinator node fails mid-batch execution, the client can retry the same batch on a different coordinator. This shouldn't cause any data integrity issues since all the operations within a batch (insert, update, or delete) as well as the entire batch itself...