Optimistic vs pessimistic locking

When two writers touch the same row

Idempotency handles the same client retrying. Locking handles different clients colliding on one row. Say a walker confirms a booking in the app while an admin cancels it in the dashboard — both read the pending booking, both decide to write, and the second write silently stomps the first. Whoever saves last wins, and the loser's change vanishes with no error. This is the lost update problem.

The trap is that plain "read it, decide, write it back" (check-then-act) has a gap between the read and the write where the other writer sneaks in. Two strategies close that gap, and knowing when to reach for each is a real interview signal.