Lightweight transactions

As discussed before, Cassandra provides eventual consistency rather than immediate consistency, which means data written will eventually be consistent across multiple replicas of the data. This has implications on the data returned by read queries. There is a possibility that reads could return stale data depending on how writes and reads are configured (the consistency levels at which both queries are performed). Strong consistency, which means reading the most recently written value, can be achieved using quorum reads and writes. But what if strong consistency is not enough? What if we have some operations to perform in sequence that must not be interrupted by others, that is, we must perform them one at a time, or make sure that any that we do run concurrently get the same results as if they really were processed independently. Cassandra provides lightweight transactions with linearizable consistency to ensure a transaction isolation level similar to the serializable level offered by RDBMSs. They are also known as compare and set transactions. You can use lightweight transactions instead of durable transactions with eventual/tunable consistency for situations that require the nodes in the distribution system to agree on changes to the data.