Two Cassandra BATCH writes that tie on timestamp can leave a durable state neither batch wrote

Sources: theconsensus.dev post, HN discussion
Summary: Phil Eaton runs an accounting workload against a three-node cluster on the pre-release cassandra-6.0 branch and reproduces the behavior by hand. Batch timestamps are client-generated and Cassandra breaks a tie per cell by keeping the greater value rather than per row, so two batches issued at the same explicit timestamp, one writing 100 and 1900 and the other writing 1800 and 200, leave 1800 and 1900 in the table, a sum of 3700 against a two-account invariant of 2000. The article also shows plain quorum updates violating the invariant on 939 of 1500 concurrent reads, and cross-partition BATCH holding atomicity but not isolation.
Why it matters: This is documented last-write-wins conflict resolution rather than a defect, which is what makes it easy to miss when modelling a ledger on Cassandra.
Follow-up: Track Accord, the strictly serializable cross-partition option, which arrives when Cassandra 6 is released. The article was read only to the fetcher's 20,000 character truncation, which falls before its Accord section.