Skip to content

CONCEPT Cited by 1 source

Distributed isolation coupling cost

Distributed isolation coupling cost is the thesis that isolation-level strictness in a distributed database is not just a concurrency-correctness knob — it is a coupling lever. Stricter levels force events that could have executed independently to coordinate with each other across shards, bounding the scalability of the whole system.

Canonical framing, verbatim from Sugu Sougoumarane's PlanetScale pedagogy post: "The more loosely coupled components are in a distributed system, the better it scales. This rule applies to distributed databases, too, and the isolation level plays a big part in this." (Source: sources/2026-04-21-planetscale-pitfalls-of-isolation-levels-in-distributed-databases.)

The mechanism

A transaction running under Serializable or SnapshotRead requires the database to guarantee either:

  1. A strict ordering of all concurrent transactions — which on a sharded database requires a centralised concurrency control mechanism (every transaction round-trips a global lock manager or coordinator); or
  2. A globally consistent clock — which is either hardware- backed (Google Spanner's TrueTime, with atomic clocks + GPS in every datacentre) or physically impossible with the precision needed for strict serialisability in general topologies.

"Both these approaches essentially attempt to tightly couple events that could have otherwise executed independent of each other." (Source: same.)

The cost is paid on every cross-shard transaction whether or not the application actually needs the ordering guarantee. If the application could have tolerated slightly stale reads or non-transactional visibility, the system is doing unnecessary work.

The load-bearing example

Sougoumarane's international retail order worked example — SELECT exchange_rate then INSERT order — is contention-free at the application altitude (the application doesn't care if the rate changes after the read). Under Serializable or SnapshotRead:

  • Single-node database: the exchange-rate-updater process is blocked for the duration of the order transaction.
  • Sharded database (exchange rates + orders on different shards): the system must coordinate a cross-shard snapshot timestamp or a distributed lock — the coupling cost is paid regardless of whether any other transaction is actually contending.

Under READ COMMITTED on a sharded database:

  • No coordination needed. Each shard commits independently at its own rate. Scales.

The 2PC interaction

Distributed transactions spanning multiple shards ([[concepts/ atomic-distributed-transaction|2PC]]) interact with isolation in a second coupling dimension. If 2PC commits partially (first participant committed, second delayed), the database must:

  • Prevent readers from seeing the first commit until the second completes, or
  • Prevent readers from seeing the second commit if they already observed pre-first-commit state.

"The database has to do additional work to support the isolation guarantees for distributed transactions. What if the application could tolerate these partial commits? Then we are doing unnecessary work that the application doesn't care about." The proposed escape is the ReadPartialCommits level — a new isolation-level design point that lets 2PC-era applications opt out of in-flight-distributed-commit visibility coordination. (Source: same.)

Availability consequence: "excessive use of 2PC reduces the overall availability and latency of a system. This is because your effective availability will be dictated by the worst performing shard."

Prescription

The three-part prescription in the same post:

  1. Prefer READ COMMITTED as the application's default isolation. Upgrade specific reads via on-demand Serializable reads (SELECT … FOR UPDATE / LOCK IN SHARE MODE). The application pays the locking cost only where correctness requires it.
  2. Avoid multi-statement transactions where possible. A shorter transaction holds fewer locks for shorter durations and is less likely to couple independent events.
  3. Avoid distributed transactions in sharded databases. Design shard boundaries so transactionally-related rows live on the same shard. Where cross-shard writes are unavoidable, prefer weaker primitives like [[patterns/ordered-commit- without-2pc|ordered commit without 2PC]] over full 2PC.

Canonicalised as [[patterns/lowest-isolation-plus-explicit- locks]].

Relationship to the CAP-theorem choice

Coupling cost is orthogonal to the ACID C axis (which is about invariants within a single node) and adjacent to the [[concepts/availability-vs-data-loss- tradeoff|availability/data-loss tradeoff]]. A system choosing AP (Cassandra, DynamoDB default) pays no coupling cost because it offers no cross-shard isolation. A system choosing CP with strong isolation (Spanner, CockroachDB) pays the full coupling cost. Systems like Vitess occupy a middle ground — offering single-shard ACID + weak cross-shard guarantees as the default, with explicit opt-in to 2PC or ordered-commit for the cross-shard minority of transactions.

Seen in

Last updated · 550 distilled / 1,221 read