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
Crash the transfer at every point
Asha sends Bilal ₹500 as four writes. First let each autocommit and crash between them; then wrap them in one transaction.
Step 1 of 5
Four writes, one transfer
A transfer row with the client’s idempotency key, a debit, a credit and two ledger rows. Sent without BEGIN, each is its own transaction.
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
“A wallet payout debits your database, then calls a bank partner’s credit API. How do you keep the two in step?”
Your move. Pick an approach:
Deep dive 2 of 4
Interviewer
“Your transfer’s COMMIT comes back as a connection error. The user taps retry. What does the service do?”
Your move. Pick an approach:
Deep dive 3 of 4
Interviewer
“A payments ledger must survive losing the primary machine entirely. How do you configure commits?”
Your move. Pick an approach:
Deep dive 4 of 4
Interviewer
“Checkout opens a transaction, locks the order rows, then calls the payment gateway, which sometimes takes seconds. Is that fine?”
Your move. Pick an approach:
Build-up · 5 steps
Where does “committed” get said?
A commit record travels from RAM to disk to a standby. Each setting decides at which stage the client hears OK, and so what that OK survives.
Step 1 of 5
Into the log buffer
Every change is appended to a log buffer in RAM. Acknowledge here, with PostgreSQL’s synchronous_commit off or InnoDB’s setting 0, and a crash loses up to about 0.6 or 1 second of commits.