Reliability & correctness

Distributed locks & holds

Stop two processes from claiming the same thing at once — a seat, a driver, a time slot.

Bookings and dispatch need exclusivity across many servers. A short-lived lock or hold in a shared store marks an item as taken while the rest of the process finishes.

See it in action

Step through the scenarios on the diagram.

1/3Server A sets lock:seat:12A only if it doesn't exist — it succeeds and gets fencing token 33.

Server A: — Wants seat 12A
Server B: — Also wants seat 12A
Lock store: — lock:seat:12A with a TTL
Bookings DB: — Checks the fencing token

How it works

Set a key only if absent, with a TTL (SET NX EX) so crashed holders release automatically.
Or use database row locks / conditional updates (available ≥ qty).
Fencing tokens prevent a stale holder from acting after its lock expired.

Trade-offs

Clock and network issues make cache-based locks imperfect; critical money paths should rely on database constraints.

Distributed locks & holds

See it in action

How it works

Trade-offs

Seen in

Components involved

Related concepts