Layer 3 · Go deeper · 8 min
Go deeper
Size it, build it, then make the calls an interviewer will push you on.
Back of the envelope
Size it up
Tap through each step of the arithmetic.
How long can the retry loop sleep before it gives up?
Build-up · 6 steps
Watch a lost update, then close it
One wallet, two debits, read-then-write code. Watch where the money goes, what PostgreSQL’s REPEATABLE READ does instead, and the one-statement fix.
Step 1 of 6
Two debits, one row
The wallet holds ₹500. A ₹300 food order and a ₹200 subscription renewal reach two app servers at the same moment, and both run the obvious code: read the balance, check it, write back the result.
4 interview moments
You’re the candidate
The interviewer pushes on the hard parts. Pick an approach and see how it holds up.
Deep dive 1 of 4
Interviewer
“Your wallet service runs on MySQL at the default level. Two debits can hit one wallet at once. How do you make each debit safe?”
Your move. Pick an approach:
Deep dive 2 of 4
Interviewer
“Rule: at most two active tatkal holds per user. On PostgreSQL, a double-tap just created a third. How do you enforce the limit?”
Your move. Pick an approach:
Deep dive 3 of 4
Interviewer
“Twenty workers pull jobs from a table and keep queueing behind each other. How should each worker claim jobs?”
Your move. Pick an approach:
Deep dive 4 of 4
Interviewer
“On MySQL, signup checks a username is free with SELECT … FOR UPDATE, then inserts it. Deadlocks (1213) follow. What do you change?”
Your move. Pick an approach:
Build-up · 5 steps
Why user 9 waits on user 7’s lock
At InnoDB’s REPEATABLE READ, locking reads lock index ranges, not just rows. Follow one query, then see why “check, then insert” deadlocks.
Step 1 of 5
One locking read
The holds table has a non-unique index on user_id holding 3, 7, 7, 12 and 20. At InnoDB’s default REPEATABLE READ, T1 runs SELECT … WHERE user_id = 7 FOR UPDATE.