Payments system design

Questions to ask the interviewer

The design in short

A payment is a promise about money. A customer presses Pay and expects two things: a quick answer at checkout, and a charge that is right. The shop must take payments fast and must never get the money wrong. The interview is about both, and about the moments when they pull against each other.

Count it. The brief says about a million payments a day. Most of them arrive in the busy hours, so plan for the peak: 20 a second. The bank needs about 1 s to charge a card, and checkout must answer in under 500 ms. Write those numbers side by side before you draw a single box.

Two companies, one payment. The shop keeps its own record of each payment. The Payment Provider and the customer’s bank keep theirs. Each record changes at its own time, and only the bank moves the money. Ask where each record lives, and which side can tell you about the other.

Items to draw on the whiteboard:

• the Pay button and the servers behind it
• where a payment is saved before anything else happens
• how the charge reaches the Payment Provider
• where the result is written when the bank answers

Slow answers are normal. The bank takes about a second, and checkout must answer sooner. So think about what checkout says while the bank decides. A customer can see the result a moment later; a checkout that hangs loses the sale. Decide which part of the work must finish before checkout answers, and which part can follow.

Stay inside the brief. Fraud checks, refunds and payouts to sellers are real parts of a payment system, and each one makes a fair follow-up question. Keep this interview to taking each payment once, quickly and correctly.

Wire it in GonnaCrash and watch every payment reach the bank once.