Explain Lightweight Transactions (LWT) & Compare-and-Set in Databases

27 / 66

Apache Cassandra

Lightweight Transactions (LWT) & Compare-and-Set

Understand how Cassandra achieves linearizable compare-and-set semantics despite its eventually consistent design.

Cassandra is fundamentally an eventually consistent, AP-leaning system, but certain use cases — like ensuring a username is unique, or implementing optimistic locking — require linearizable consistency: an operation that only succeeds if a condition is atomically checked and satisfied at the moment of the write. This is provided by Lightweight Transactions (LWT), using IF clauses such as IF NOT EXISTS or IF column = value.

A normal Cassandra write is like shouting an update to everyone in the room without waiting to see if it's already been changed. An LWT is like calling a formal meeting, taking attendance, checking the current state, voting on whether to accept the change, and only then confirming it — much slower, but guarantees no conflicting change slips through.

Key Concepts

Under the hood, LWTs use a variant of the Paxos consensus protocol to achieve linearizability across replicas, rather than the normal single round-trip write path. This makes LWTs significantly more expensive — typically 4 round trips between replicas instead of 1 — because Paxos requires a prepare/promise phase and an accept/accepted phase (and sometimes a commit phase) to reach agreement.

Paxos consensus protocol4 round trips

LWTs are scoped per partition, meaning they only guarantee atomicity and linearizability for conditional operations on a single partition; they cannot be used to implement multi-partition transactions.

per partition

Because of the performance cost, LWTs should be reserved for cases that truly require compare-and-set semantics (uniqueness constraints, distributed locks, leader election) rather than general-purpose writes.