Serializable Snapshot Isolation keeps snapshot isolation's non-blocking reads but adds runtime detection of read-write anti-dependencies and aborts transactions that could produce a non-serializable result. Explain how that detection works, why it aborts transactions that would in fact have been fine, and how you would decide whether to run a high-throughput OLTP system on it.

## The idea Strict two-phase locking achieves serializability pessimistically: readers block writers, writers block readers, and correctness costs latency. Snapshot isolation achieves scalability by never blocking reads, at the cost of correctness — it validates only write sets. Serializable Snapshot Isolation is the optimistic middle: keep MVCC snapshot reads exactly as they are, *observe* the read-write conflicts the snapshot rule ignores, and abort transactions when the observed pattern could not have come from any serial order. ## The theorem it rests on Dependencies between concurrent transactions come in three forms. Write-read: B reads what A wrote. Write-write: B overwrites what A wrote. Read-write, called an **anti-dependency**: A read an item, and B then wrote a newer version — so any equivalent serial order must place A before B. Serializability means this dependency graph is acyclic. Snapshot isolation structurally rules out cycles that would need a write-read or write-write edge between concurrent transactions: a transaction never reads a concurrent write, and concurrent writes to one item cannot both commit. So any cycle that survives must be built with anti-dependency edges — and Fekete et al. proved something sharper: **every non-serializable snapshot-isolation history contains a cycle with two consecutive anti-dependency edges**. There is a transaction in the middle — the **pivot** — that has an incoming anti-dependency (someone read what it wrote) and an outgoing one (it read something someone else wrote). This is what makes runtime enforcement cheap. SSI never materialises the whole graph or searches it for cycles. It maintains two bits per transaction — "has an inbound conflict", "has an outbound conflict" — and fires when both are set on the same transaction and the commit ordering makes the situation unsafe. ## Tracking reads To notice an anti-dependency, the engine must remember what each transaction read. It does that with non-blocking read markers — often called SIREAD locks, though they are not locks in the blocking sense: they conflict with nothing and never make anyone wait; they are bookkeeping. They are recorded at the row level for point reads, and at index-range or page level for scans, so that a *predicate* read ("all reservations for room 5 today") can be matched against a later insert into that range. Markers must persist past the reading transaction's own commit, because the write that conflicts with a read may arrive later and the pivot may only be revealed then. ## Why it aborts innocent transactions Three independent sources of false positives, and being able to name them is the mark of real understanding: 1. **The dangerous structure is necessary, not sufficient.** A pivot with both edges *can* occur in perfectly serializable executions. SSI aborts on the pattern rather than proving a cycle exists, because proving it would require the full graph and, worse, information about transactions that have not finished. 2. **Read tracking is coarse.** A range read is registered against index pages or ranges, so a write anywhere in that range counts as a conflict even if it touches no row the reader would have returned. Fine granularity costs memory; coarse granularity costs precision. 3. **Memory pressure degrades precision further.** The tracking structures are bounded; when they fill, the engine summarises per-transaction read sets into coarser aggregates and, in the extreme, treats old committed transactions conservatively. Long-running transactions are the usual cause, because they keep read markers and old snapshots alive. The consequence is that abort rate is not purely a function of true conflicts; it is a function of true conflicts *plus* transaction duration *plus* read-set breadth. ## Operating it **Retry is not optional.** SSI converts anomalies into transient serialization failures, and a system without a bounded retry with exponential backoff and jitter converts them into user-visible errors. The retry must wrap the entire unit of work so it re-reads under a fresh snapshot, must be capped, and must be able to distinguish serialization failures from constraint or domain errors, which must never be retried. **Side effects must be outside.** Anything not rolled back by the database — emails, payment calls, message publishes — cannot live inside a transaction that may be aborted and replayed. Move them after commit, ideally via an outbox. **Transactions must be short and narrow.** Every extra millisecond and every extra row read widens the window and the read set. Analytical scans inside serializable transactions are the fastest way to make abort rates unmanageable; route them to a read-only path or a replica. **Mark read-only work as read-only.** Engines can exempt read-only transactions from much of the tracking, and a deferrable read-only mode can wait for a snapshot guaranteed safe, avoiding aborts entirely for reporting queries. **Measure before and after.** The decision hinges on the actual abort rate at production concurrency, the added latency of the retry tail, and the CPU cost of tracking. A conflict rate of a fraction of a percent is comfortable. Double-digit abort rates mean retries dominate throughput, and the answer is to reduce contention structurally — partition hot keys, shorten transactions, move counters out of the critical path — not to widen the retry budget. ## When not to use it If only a handful of code paths carry cross-row invariants, it can be cheaper and more predictable to leave the system on snapshot isolation and harden those paths individually with constraints, materialized conflicts, or explicit locking. SSI is the right default when invariants are numerous, ad hoc, or written by many teams — when you would rather pay a uniform tax than audit every new query for write skew.