Stackbook Logo
data-consistencyestablished · low operational burden

Optimistic Locking

Also known as: optimistic-concurrency, version-field, cas, compare-and-swap

Intent

Prevent lost updates in concurrent writes without blocking, using version numbers or timestamps to detect conflicts.

Problem

Two users edit same record. Second save overwrites first. Pessimistic locking (SELECT FOR UPDATE) blocks and deadlocks.

Forces

  • •High read, low conflict workloads
  • •No blocking: reads never wait, writes rarely conflict
  • •Conflict detection at commit time
  • •Works with: ORM, HTTP ETags, distributed systems

Solution

✓ When to Use

  • •Low conflict rate (<1% of writes)
  • •Read-heavy workloads
  • •Distributed systems (no distributed lock needed)
  • •REST APIs with ETags

✗ When Not to Use

  • •High conflict rate (pessimistic better)
  • •Long transactions (version changes during read)
  • •Business requires last-write-wins (rare)

Pros

  • +No blocking: reads never wait
  • +No deadlocks
  • +Scales: no lock manager
  • +Natural fit for HTTP (ETags)

Cons

  • −Retry logic required (application complexity)
  • −Lost update if retry not implemented
  • −High conflict → retry storm
  • −Timestamp precision issues

Cost Profile

Infrastructure

None — column + query pattern

Operational

Low — monitor conflict rate

Cognitive

Low — standard pattern

Failure Modes

  • Lost update: retry not implemented, conflict silently ignored

  • Retry storm: high conflict, exponential backoff needed

  • Timestamp collision: same millisecond, false conflict

  • Version overflow: integer wraps (use BIGINT)

  • Stale read: read old version, write succeeds but based on stale data

Real-World Examples

Alternatives

  • pessimistic-locking
  • distributed-lock
  • event-sourcing
  • cas

Related Patterns

  • pessimistic-locking
  • distributed-lock
  • event-sourcing
  • cas
  • etag

Competency Domains

data consistencydata statedistribution communicationreliability opseconomics evolution