Layer 3 · Go deeper · 6 min
Go deeper
Size it, build it, then make the calls an interviewer will push you on.
Build-up · 5 steps
One guarded debit, two levels
A top-up and a debit hit the same wallet row on PostgreSQL. Watch what the debit does when it meets the newer row.
Step 1 of 5
A tops up, uncommitted
Wallet 7 holds ₹500. Session A adds ₹200 and hasn’t committed yet, so it holds the row lock.
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
“Which isolation level, and which write, for a payment service’s wallet debit?”
Your move. Pick an approach:
Deep dive 2 of 4
Interviewer
“Tatkal: two sessions run UPDATE berths SET passenger_id = 502 WHERE id = (first free berth subquery) on PostgreSQL READ COMMITTED. Safe?”
Your move. Pick an approach:
Deep dive 3 of 4
Interviewer
“You’re moving from MySQL to PostgreSQL. Bookings did SELECT … FOR UPDATE on an empty range, then INSERT. What now?”
Your move. Pick an approach:
Deep dive 4 of 4
Interviewer
“Gap-lock deadlocks keep hitting your MySQL order service. Do you switch it to READ COMMITTED?”
Your move. Pick an approach:
Build-up · 5 steps
One MySQL transaction, two views of a table
Session A expires pending orders with ids 100 to 200 at MySQL’s default REPEATABLE READ while others keep inserting.
Step 1 of 5
A’s first SELECT counts 2
The first plain SELECT creates A’s read view. Orders 105 and 130 fall in the range, so the count is 2.