Back to notes

Ways to Handle Editing Conflicts

concurrencycollaborationsystems

Pessimistic Locking#

Stop the conflict before it can happen. One person acquires a lock, makes their changes, and everyone else waits until the lock is released.

  • Trade-off: Simple to reason about, but kills throughput when contention is high. The lock becomes a bottleneck.
  • Good for: High-conflict resources where merge complexity is severe (e.g., editing a binary file, Terraform state).
  • Bad for: Most collaborative editing — people are blocked waiting for a resource they may only touch briefly.

Last-Write-Wins#

Let everyone save freely. If two people change the same thing, the newest save silently replaces the older one.

  • Trade-off: Maximum throughput, zero coordination overhead. But you lose data silently with no notification.
  • Good for: Conflict-free data (e.g., each user writes to their own fields), metrics, logs, eventual-consistency scenarios.
  • Bad for: Any situation where data integrity matters and concurrent edits produce meaningful conflicts.

Optimistic Concurrency Control (OCC)#

Let everyone edit freely, but check before saving. On save, verify nothing changed since you read. If it did, reject the save and force the user to reconcile.

  • Trade-off: Best of both worlds for moderate contention — no blocking during reads, but safe writes. Requires conflict-resolution logic on the client.
  • Common implementation: Include a version number or timestamp on the resource; increment on every write. The update query includes WHERE version = :old_version — if zero rows match, someone else changed it first.
  • Good for: Document editing (Google Docs, Notion), API resources, most web applications.
  • Bad for: Extremely high-frequency writes to the same record — retry overhead becomes significant.
  • Relation to Presence: Real-time presence indicators (like WebSockets showing "Alice is editing") are a helpful courtesy, but they do not guarantee safety. Correctness must still be enforced by OCC version checks on the server-side update endpoint.

“Presence is helpful. OCC is still required.”
Sockets tell you something happened; the version check on save is what actually stops a stale write from landing. (See Presence Awareness).