Serializable transactions across keys

Moving money between two accounts, booking the last seat or keeping an index in step with its table all need a transaction that touches several keys at once and cannot be interleaved badly with others. Serializable isolation promises that the result equals some one-at-a-time order of the transactions. Weaker levels, which are often the default, let anomalies through: under snapshot isolation two transactions can each read a value, write a different row, and together break a rule neither broke alone (write skew). Strict serializability adds a real-time rule on top: once a transaction has committed, every later one sees it.

Doing this inside one server is well understood; PostgreSQL, for example, implements Serializable with Serializable Snapshot Isolation and aborts a transaction that would break the serial order. Doing it across machines needs a commit protocol that spans shards and a way to order transactions, such as a timestamp oracle, synchronised clocks or a single sequencer. Many distributed stores offer transactions only within one partition, or only at a weaker level.

To tell whether a system really handles this, check what a transaction may span (one row, one partition or any keys), which isolation level is the default and which are offered, and what the client must do when a transaction is aborted for a conflict (usually retry it). Independent tests such as Jepsen analyses are the best evidence that the promised level actually holds under faults.