You have a payment system. Two users try to spend from the same wallet balance at the same time.
Both read $200. Both want to spend $150. Both see enough balance. Both write the deduction.
The wallet is now at -$100. How do you stop this?
A) Pessimistic locking — SELECT FOR UPDATE on the wallet row. One transaction blocks until the other commits.
B) Optimistic locking — read the row with a version number, only write if version hasn't changed since you read it. Retry on conflict.
C) MVCC — let both reads see a consistent snapshot, rely on the database to detect write conflicts at commit time.
D) Serializable isolation — set the transaction isolation level to SERIALIZABLE and let the database handle it.
All four are real production strategies. One of them will silently allow double-spend under concurrent load. One will destroy your throughput on a high-write table. One is almost always the wrong default choice despite being the "safe" option.
Pick one — and tell me which one you'd actually ship in a payment system processing 10K transactions/second.
Full breakdown in the comments.
If you're building anything with concurrent writes — share this. It's the class of bug that costs money before you catch it.
Drop your answer 👇
