In HCD, a write operation is atomic at the partition level, meaning the insertions or updates of two or more rows in the same partition are treated as one write operation. A delete operation is also atomic at the partition level.

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

HCD uses client-side timestamps to determine the most recent update to a column. 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.

HCD write and delete operations are performed with full row-level isolation. This means that a write to a row within a single partition on a single node is only visible to the client performing the operation. The operation is restricted to this scope until it is complete. All updates in a batch operation belonging to a given partition key have the same restriction. However, a batch operation is not isolated if it includes changes to more than one partition.

Writes in HCD are durable. All writes to a replica node are recorded both in memory and in a commit log on disk before they are acknowledged as a success. If a crash or server failure occurs before the memtables are flushed to disk, the commit log is replayed on restart to recover any lost writes. In addition to the local durability (data immediately written to disk), the replication of data on other nodes strengthens durability.

You can manage the local durability to suit your needs for consistency using the commitlog_sync property in the cassandra.yaml file. Set the option to either periodic or batch.