A $200 wallet balance, two simultaneous $150 deductions, and four different database strategies to prevent double-spending. One silently fails under production load. Here's the analytical breakdown of what actually works at scale.
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.
This is the classic double-spend problem, and it's the class of bug that costs money before you catch it. The failure mode is silent. No exceptions thrown. No error logs. Just money vanishing from your system.
The question isn't whether this can happen. It's which concurrency control strategy you'll use to prevent it, and what trade-offs you're willing to accept.
The Four Real Production Strategies
A) Pessimistic Locking
SELECT FOR UPDATE on the wallet row. One transaction blocks until the other commits.
Comments
Please log in or register to join the discussion