Lightweight transactions (LWT) are Cassandra's compare-and-set: 'insert if not exists', 'update where condition'. They use Paxos under the hood — strongly consistent, ~4x slower than normal writes. Knowing when to reach for them is one of the higher-leverage skills in Cassandra modeling.
The Paxos round-trip cost
Each LWT does 4 round-trips: prepare, promise, propose, accept. Normal write is 1. So latency is 4x, throughput is ~1/4. Plan capacity accordingly. Don't use LWT on hot paths.
Right cases
Unique-username creation: INSERT ... IF NOT EXISTS. Idempotency keys for payments: same idea. Optimistic state-machine transitions: UPDATE ... IF status='PENDING' to atomically move to 'PROCESSING'. Distributed leader election with TTL.
Wrong cases
Counter increments — use real Cassandra counters or a separate increment service. Every write going through LWT — you're using the wrong database. Cross-partition transactions — LWT is single-partition only.
BATCH + LWT
You can batch LWT statements only if they all target the same partition. Cross-partition LWT in a batch is rejected. Use this for related state transitions on one entity.
Operational watch-outs
Paxos state lives in system.paxos. Gets cleaned on commit. If a coordinator dies mid-round, abandoned Paxos rows accumulate — usually small but can stack on heavily-LWT workloads. Monitor.