Once more than one node can accept a write, two of them can change the same thing at once — and something has to decide what the truth becomes. This lesson covers how concurrent writes are even detected (why wall-clock timestamps lie, and what version vectors do instead), the resolution strategies from the data-losing simplicity of last-write-wins up to the mathematical guarantees of CRDTs, and then the other half of the problem: making one operation atomic across several nodes. Why two-phase commit is correct but blocking and avoided at scale, and why sagas trade atomicity for availability with compensating actions.

Conflict resolution & distributed transactions

The topologies lesson ended on a warning it deferred: the moment you leave single-leader — multi-leader, leaderless, or an offline-first client — two nodes can accept writes to the same data concurrently, and when those writes meet, the system faces a question single-leader never asks: which write is the truth, or are they both? This lesson is the two hard halves of that question. First, conflict resolution: reconciling concurrent writes to the same data. Second, distributed transactions: making a single operation atomic across data that lives on different nodes. Both are the price of distributing state, and both are why staying single-leader is worth so much.

First problem: how do you even know two writes conflict?

Before resolving a conflict you must detect one, and the naive detector is broken. The obvious idea — "compare wall-clock timestamps, the later one is newer" — fails because clocks lie. Different machines' clocks drift and are skewed relative to each other (NTP keeps them close, not identical), so a write that actually happened second can carry an earlier timestamp than one that happened first. Ordering distributed events by wall-clock time is unreliable, and building correctness on it is a classic distributed-systems bug.

The fix is logical clocks — counters that capture causality rather than time. A version vector (or vector clock) keeps a per-replica counter so the system can tell, for any two writes, whether one causally preceded the other (one built on the other — keep the later) or they were truly concurrent (neither saw the other — a genuine conflict to resolve). This is the same causality from the consistency-models lesson, made into a mechanism: version vectors are how a system knows two writes are concurrent instead of guessing from timestamps.

Resolving the conflict

Once you know two writes are concurrent, four strategies, from lossy-simple to correct-complex:

Last-write-wins (LWW). Pick one by timestamp (or any deterministic tiebreak), discard the other. Trivial to implement and Cassandra's default — and it silently loses data: the discarded write just vanishes, with no error, no trace. If two users concurrently edit a field, one edit is gone. LWW is acceptable only when losing a concurrent write is genuinely fine (a last-seen timestamp, a cache entry) and never when the writes are independently valuable.
Application-level merge. Surface the conflict and let code or the user reconcile — the git-merge model ("both changed this; here are both versions"). Correct, but pushes work onto the app and sometimes the human.
Version vectors with siblings. The datastore keeps both conflicting versions ("siblings") and hands them to the application on the next read to merge deliberately, instead of silently dropping one. Dynamo/Riak do this — no data lost, resolution deferred to someone who understands the data.
CRDTs (Conflict-free Replicated Data Types). Data structures designed so that concurrent updates always merge deterministically, with no coordination and no lost writes — the merge is baked into the type's math (it's associative, commutative, idempotent, so replicas converge regardless of order). A grow-only counter, an add/remove set, a collaborative-text sequence: each has a CRDT that guarantees every replica reaches the same state once they've exchanged updates. CRDTs are how Google Docs-style collaborative editing and modern offline-sync engines avoid conflicts by construction. The cost is that not every data model has a natural CRDT, and they carry metadata overhead — but where they fit, they're the strongest answer: convergence as a mathematical property, not a hope.

Increment each replica a few times while they're offline, then sync. With last-write-wins one replica's increments silently vanish; with a CRDT counter both are preserved and the replicas converge to the true total. Same edits, one loses data.

Conflict strategy — a shared counter, two offline replicas

Replica A (last write)+0

Replica B +0

Once two writes are concurrent, something must resolve them. Last-write-wins is trivial and Cassandra's default — and it silently loses data: the discarded write just vanishes. A CRDT is a data type designed so concurrent updates always merge deterministically (the merge is associative, commutative, idempotent), so replicas converge with no coordination and no lost writes — how collaborative editors work. Not every model has a natural CRDT, but where one fits, convergence is a mathematical guarantee, not a hope.

Second problem: one operation, many nodes

The other half. A single logical action must sometimes touch data on different nodes atomically — a cross-shard transfer, or an operation spanning several services — and you want the ACID all-or-nothing guarantee across all of them: either every part commits, or none does.

Two-phase commit (2PC) is the classic protocol. A coordinator drives two rounds:

Prepare — ask every participant "can you commit this?" Each does the work, durably prepares, locks what's needed, and replies yes (a promise it can commit) or no.
Commit — if all said yes, the coordinator tells everyone "commit"; if any said no, "abort." Participants finalize accordingly.

2PC is correct — it genuinely gives atomicity across nodes. But it has a crippling weakness explored in the callout, and it's slow (two round trips plus a durable write at each participant) and it reduces availability (any participant being down blocks the whole transaction). This is why high-scale systems mostly avoid distributed transactions rather than optimize them.

Sagas are the availability-friendly alternative. Instead of one atomic transaction across nodes, a saga is a sequence of local transactions, each with a defined compensating action that undoes it. Book flight → charge card → reserve hotel; if the hotel step fails, run the compensations in reverse — refund the card, cancel the flight. No distributed locks, no coordinator holding everyone hostage, each step is a normal local commit. The price: no isolation (intermediate states are visible — for a moment the card is charged but the hotel isn't booked) and the burden of writing correct compensations for every step. Sagas trade the strict atomicity of 2PC for availability and are the backbone of long-running cross-service workflows — the distributed-patterns stage builds them properly alongside the outbox pattern.

The write that vanished, and the coordinator that took everyone hostage

Two failures, one per half of this lesson, and both are quiet.

LWW silent data loss. Two users edit the same group's settings within the same second on a multi-leader (or offline-syncing) system. Both writes succeed locally, both get acknowledged, both users see their change. The writes replicate, LWW compares timestamps, and the "earlier" one is discarded — permanently, with no error anywhere. One user's change simply evaporates on the next sync, and there's no log line to find because from the system's view nothing went wrong: LWW did exactly what it promises. This is the trap of choosing LWW for data where writes are independently valuable — it converts a conflict into silent data loss. The defenses are the strategies above: keep siblings and merge, or use a CRDT so both changes survive, or — the cheapest — don't allow concurrent writers in the first place (stay single-leader).

The 2PC blocking problem. In two-phase commit, after a participant votes yes in the prepare phase, it is bound — it has promised to commit and is holding locks, waiting for the coordinator's final verdict. Now the coordinator crashes between prepare and commit. The participant cannot unilaterally commit (others may have voted no) and cannot unilaterally abort (others may have committed) — it is stuck holding its locks indefinitely, blocking every other transaction that needs those rows, until the coordinator recovers. A single coordinator failure can freeze a shard. This is the reason 2PC is feared at scale: it's not that it's slow, it's that its failure mode is a distributed deadlock waiting on one machine. It's exactly why sagas (no coordinator, no held locks, compensations instead) win for anything long-running.

Where this lives in Fable

Here is the whole payoff of Fable's single-leader choice: it has no write conflicts to resolve, so this entire first half doesn't apply. One Postgres node is the only writer, so there's never a concurrent pair of accepted writes to the same row to reconcile — no LWW, no version vectors, no CRDTs, no silent-data-loss trap. The one place concurrent writers could collide — two settlement confirms on the same debt — Fable doesn't resolve after the fact, it prevents with the advisory lock, serializing them so a conflict never forms. That's the single-node luxury: prevent conflicts with a lock rather than resolve them with a merge. Two forward-looking connections. First, money specifically forbids LWW — a payment must never be the write that silently vanishes — so if Fable ever went offline-first (each phone a multi-leader accepting edits offline), it could not use last-write-wins for anything financial; it would need explicit merge or compensations, which is a strong reason it keeps the server the single source of truth and the client a cache. Second, the settlement flow already has a saga-flavored shape: a marked_paid settlement isn't yet final — the recipient can dispute it or either party can cancel it before it reaches the terminal confirmed state, and the payer even gets a short (30-minute) window to cancel after marking paid — each of those transitions reverses an in-flight step rather than committing it, which is precisely the compensating action shape of a saga applied to money that must be undoable up until it's final. And the cross-concern atomicity Fable does face — "record the expense and notify members" spanning Postgres and the push path — is the exact case for the outbox pattern from the queues lesson rather than a 2PC across systems. Fable's stance throughout: prevent conflicts by staying single-writer, and where an operation must span concerns, prefer compensations over distributed commit.

Go deeper

Kleppmann — Designing Data-Intensive Applications, ch. 5 (conflicts) & ch. 9 (2PC) — The rigorous treatment of concurrent-write detection, version vectors, last-write-wins data loss, and the 2PC blocking problem — the source this lesson compresses.
crdt.tech — CRDT resources & papers — The hub for Conflict-free Replicated Data Types: the intuition, the algebra that guarantees convergence, and the real libraries — for when a natural merge is exactly what you need.
Chris Richardson — the Saga pattern — A clear, practical spec of sagas and compensating transactions as the alternative to distributed 2PC — the on-ramp to the distributed-patterns stage.

Check yourself

Answer out loud, as if an interviewer asked. If you hand-wave, reread that section.

Why can you not reliably order two writes on different machines by their wall-clock timestamps? What does a version vector let you determine that a timestamp cannot?
Rank last-write-wins, application merge, version-vector siblings, and CRDTs by how much data they can lose. Explain precisely how LWW loses a write with no error, and when it is nonetheless acceptable.
What guarantee does a CRDT provide that the other strategies do not, and what property of its merge operation makes that guarantee hold regardless of update order? Give an example data type.
Describe the two phases of 2PC. Then explain the blocking problem: what state is a participant in after voting yes, and why does a coordinator crash freeze it?
Contrast 2PC and sagas on atomicity, isolation, and availability. What does a saga use instead of a rollback, and what visible anomaly do you accept in exchange?
Fable resolves no write conflicts at all. Explain why single-leader makes that true, how the settlement advisory lock prevents rather than resolves the one hazard, and why money data specifically could never use LWW if the app went offline-first.

Conflict resolution & distributed transactions

Conflict resolution & distributed transactions

First problem: how do you even know two writes conflict?

Resolving the conflict

Second problem: one operation, many nodes

Go deeper

Check yourself

On this page