Layer 3 · Go deeper · 6 min
Go deeper
Size it, build it, then make the calls an interviewer will push you on.
Build-up · 6 steps
Watch SSI catch the two payments
User 42 has sent ₹70,000 today against a ₹1,00,000 limit. Two ₹25,000 payments run at SERIALIZABLE on PostgreSQL, one per account.
Step 1 of 6
A sums today’s transfers
Session A reads ₹70,000, so another ₹25,000 fits. The read leaves an SIRead lock on the (user_id, day) index range, a marker that never blocks anyone.
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
“Payments must respect a ₹1,00,000 daily limit summed across a user’s linked accounts. It’s the one rule you need. How do you enforce it?”
Your move. Pick an approach:
Deep dive 2 of 4
Interviewer
“A payment runs at SERIALIZABLE, calls the payment gateway, then commits. Some attempts fail with 40001. How do you retry?”
Your move. Pick an approach:
Deep dive 3 of 4
Interviewer
“The wholesaler’s day report must be right while sales and close-day run at SERIALIZABLE on PostgreSQL. How do you run it?”
Your move. Pick an approach:
Deep dive 4 of 4
Interviewer
“Your transactions are short, in memory and submitted whole as stored procedures, and nearly all touch one account. How do you make them serializable?”
Your move. Pick an approach:
Build-up · 6 steps
Watch a read-only report break serial order
A wholesaler’s billing system. A sale tags its row with the current business day, close-day moves the day on, and the day report totals the previous day.
Step 1 of 6
A sale reads day 27
The sale starts and reads the current business day, 27. It will tag its row with that day when it inserts.