Atomicity

Everything in a transaction succeeds or the entire transaction is rolled back.

In Cassandra, a write is atomic at the partition-level, meaning inserting or updating columns in a row is treated as one write operation. A delete operation is also performed atomically. By default, all operations in a batch are performed atomically. Cassandra uses a batch log to ensure all operations in a batch are applied atomically. There is a performance penalty for batch atomicity when a batch spans multiple partitions. If you do not want to incur this penalty, use the UNLOGGED option. Using UNLOGGED makes the batch operation atomic only within a single partition.

For example, if using a write consistency level of QUORUM with a replication factor of 3, Cassandra will replicate the write to all nodes in the cluster and wait for acknowledgement from two nodes. If the write fails on one of the nodes but succeeds on the other, Cassandra reports a failure to replicate the write on that node. However, the replicated write that succeeds on the other node is not automatically rolled back.

Cassandra uses timestamps to determine the most recent update to a column. Depending on the version of the Native CQL Protocol, the timestamp is provided by either the client application or the server. The latest timestamp always wins when requesting data, so if multiple client sessions update the same columns in a row concurrently, the most recent update is the one seen by readers.