May 12, 2026
When $10 starts a civil war
SQL: Incorrect by Construction
That ‘simple’ money move code had hidden traps, and the comments went feral
TLDR: The article shows how a basic money-transfer script can secretly lose money, allow overspending, or freeze when used at the same time. Commenters were split between “this is SQL misuse” and “this is normal engineering reality,” with veterans piling on fixes and tough-love warnings.
A seemingly innocent bit of banking code just got absolutely dragged by the internet. The article’s big claim is that a basic “send $10 from Alice to Bob” routine can go wrong in wildly embarrassing ways: money can vanish mid-transfer, two payments can slip through at once, and two people sending money at the same time can freeze the whole thing. In plain English, code that looks sensible on first glance can still blow up when real people click buttons at the same time.
And the comments? Instant food fight. One camp basically said, “Well… duh.” User taeric argued that SQL was made for asking questions of data, not acting like a step-by-step control script, so maybe this mess is what happens when you force it to be something it isn’t. Another crowd jumped in with battle-scarred, veteran energy: traderj0e said they’ve seen this problem “dozens of times” and dropped a cleaner one-line trick that made the whole thread feel like a live emergency room consult.
Then came the side-eye. One commenter wondered if part of the article was literally a placeholder, which is the nerd equivalent of spotting spinach in someone’s teeth during a keynote. Others escalated fast: if your app uses caching or spreads work across multiple machines, warned giancarlostoro, things can get even messier. And the hottest tough-love take of all? Design for concurrency from day one, or don’t act shocked later. The vibe was half masterclass, half public roast, with a dash of “this is why banks make engineers sweat.”
Key Points
- •The article uses a TSQL money-transfer example to show how seemingly reasonable SQL code can contain serious concurrency bugs.
- •It identifies an atomicity flaw where a transfer can debit Alice without crediting Bob if the procedure aborts midway.
- •It shows a TOCTOU race condition in which parallel transfers can both pass the balance check before either withdrawal executes.
- •The article recommends row locking with `UPDLOCK` or stronger isolation to keep Alice’s balance from changing between check and update.
- •It explains that deadlocks can still occur when opposite-direction transfers run concurrently, and proposes acquiring all required locks up front to avoid them.