System Design (High-Level Design) Module 27
Case studies: payments, money and markets interview questions
Interview questions on “Case studies: payments, money and markets”: warm-ups, then what each harder question tests and how a good answer starts.
Warm-up questions
Short questions with short answers, each answered in full.
-
Fresher to mid
What is price-time priority in an exchange's order book, and at what price does a trade happen?
An incoming order trades first with the best opposite price, the lowest ask for a buy and the highest bid for a sell, and at that price with the oldest resting order first, so each price level is a queue in arrival order. The trade happens at the resting order's price, not at the incoming order's limit. A buy of 400 at up to 100.15 against sells of 300 and 200 at 100.10 takes all 300 of the older sell and 100 of the newer one, both at 100.10, and never reaches a sell at 100.20, which is above its limit. What a limit order cannot trade rests in the book; a market or immediate-or-cancel order cancels the rest instead. A few markets share a price level by size, pro-rata, rather than by time.
From the lesson Design a stock exchange matching engine
-
Fresher to mid
What does a stockbroker's order management system do between a client's tap on buy and the exchange?
It gives the order an id and checks it: the instrument, the quantity and the price, and in the risk management system the client's funds, margin or holdings, which are blocked before anything is sent. It then sends the order to the exchange over one of the broker's few gateway sessions, which carry strict message rates. As the exchange's reports come back, the acknowledgement, fills, cancels and rejects, it applies them to the order, the client's positions and the funds, and the app reads the result from a fast cache. Reports can arrive late, twice or out of order, so each order is a state machine that only moves forward, and an order whose answer is still on its way is shown as pending at the exchange, never as failed.
From the lesson Design broker order management like Zerodha
Questions with model answers
What each question tests, the first step of a good answer and the follow-ups to expect.
-
Mid to senior
A payer's app showed "payment failed" after a timeout, the payer paid again, and the bank statement shows two debits for the same purchase. Explain how this happened, and redesign the flow so that no retry or second attempt can ever debit twice.
- What it tests
- Unknown outcomes after a timeout, one reference per payment carried through every hop, status checks before any new attempt, and the app's wording while an outcome is unknown.
- First step
- Separate the payment from its attempts. Ask whether the second try carried the first one's reference or a new one, and what the app knew when it said "failed": a refused connection proves nothing was sent, while a timeout after sending proves nothing at all.
- Follow-ups
-
- The status check also times out. What does the app show the payer?
- The payer changes the amount and pays again. Same reference or a new one?
- How does the bank answer a known reference that arrives with a different amount?
From the lesson Design UPI-style payments: flows and idempotency
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Senior to staff
The payer's bank has debited a payment, but the payee's bank answers neither the credit request, nor three status checks, nor the credit reversal request. What final status should the switch record, why, and how does the money end up in the right place?
- What it tests
- Reasoning about an outcome that cannot be learned in time, why neither failure nor plain success is safe, deemed approval, and resolution through reconciliation within a regulator's deadline.
- First step
- List the two worlds the switch cannot tell apart: the payee was credited, or was not. For each possible final status, work out who ends up with the money in each world, and look for the status that is never wrong in a way that cannot be repaired.
- Follow-ups
-
- The payee's bank comes back an hour later. What does it do with the payment?
- The payee's account was closed meanwhile.
- What does the payer's app show between the debit and the resolution?
From the lesson Design UPI-style payments: flows and idempotency
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Senior to staff
At the busiest hour, one large bank's core system slows down for ten minutes. Payment apps ask the switch for the status of every pending payment every five seconds, the switch's load triples, and the bank takes far longer to recover than the fault lasted. Explain the loop, and design status checks that let it recover.
- What it tests
- Retry and polling storms as a feedback loop, capping and spacing checks, never checking what was never sent, protecting a slow participant at the switch, and what users see meanwhile.
- First step
- Count the work: pending payments times checks per payment, all sent to the bank that is already slow. Each check competes with the debits the bank is trying to finish, so the polling itself keeps the bank slow. Then decide how many checks a payment really needs, and when.
- Follow-ups
-
- Why does checking every 5 seconds for 2 minutes leave more payments unknown than three checks over an hour?
- Which failed calls should never be followed by a status check?
- How should the switch treat new payments for that bank during the slowdown?
From the lesson Design UPI-style payments: flows and idempotency
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Senior to staff
One of your three acquiring banks carries 40 % of card payments. Within five minutes its approval rate falls from 92 % to 60 %, then recovers an hour later. Design routing that moves traffic away quickly, recovers the bank's share afterwards, does not swing traffic back and forth, and never charges anyone twice.
- What it tests
- Sliding-window approval rates, exploration to see a recovery, margins against flapping, which declines may be retried on another acquirer, and why timeouts may not.
- First step
- Separate measurement from decision. Measure approvals per acquirer over a short window, per card network and issuer, and work out how many checkouts each minute of delay costs: here about 2,560 a minute at 667 attempts a second. Then decide which declines are the acquirer's fault.
- Follow-ups
-
- Why does a lifetime approval rate fail after the bank recovers?
- Which declines may be retried at another acquirer, and which never?
- The bank fails only for cards of one issuer. What changes?
From the lesson Design an online payment gateway
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
A merchant wants one-click repeat payments, and its developers plan to keep customers' card numbers, encrypted, in their own database. What do you tell them, what should the merchant and the gateway store instead, and how does the choice change what each of them must protect?
- What it tests
- Card data scope, hosted fields and vaults, tokens bound to a card and merchant, what may be kept for display and reconciliation, and why encryption does not remove the obligation.
- First step
- Ask which systems would then store card numbers: the merchant's database, its backups, its logs and every server that decrypts them. Each one becomes part of the card data environment. Then show the path where the number goes only from the browser to the gateway's vault.
- Follow-ups
-
- What may the merchant show the customer to pick a saved card?
- The customer's card is replaced by the bank. What happens to the token?
- Which rules apply to stored card data in India?
From the lesson Design an online payment gateway
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
A support agent and an automatic returns job refunded the same order within a second of each other, and the customer received twice the amount paid. Both requests had idempotency keys. Explain why the keys did not help, and design refunds so this cannot happen.
- What it tests
- The limits of idempotency keys across different requests, invariants enforced by conditional updates, refund states, and reconciling refunds with the acquirer.
- First step
- Look at the two keys: they were different, because the requests came from different systems, so the gateway correctly treated them as two refunds. The rule that was broken is "refunds never exceed the captured amount", and nothing enforced it atomically.
- Follow-ups
-
- Why not let the support tool reuse the returns job's key?
- The first refund is still pending at the acquirer when the second arrives.
- How would you detect the money already refunded twice?
From the lesson Design an online payment gateway
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Senior to staff
Your exchange's hot standby replays the primary's input log, and both run the same code. After a failover, members report trades that differ from the reports they received before it. How can two engines that read the same log diverge, how do you find the first input where they did, and how do you prevent it?
- What it tests
- Determinism as a design rule: what an engine reads outside the log, noticing drift between copies, pinning the first differing input, and what happens to a copy that diverged.
- First step
- List everything the engine reads that is not in the log: the clock, random numbers, iteration over containers without a defined order, floating-point arithmetic, its settings and its code version. Each can give two copies different results from the same inputs. Then ask how anyone would notice a difference between the two copies before members do.
- Follow-ups
-
- The checkpoints agree at input 5,000 and differ at 6,000. How do you find the exact input?
- Some orders expire at a set time. Where does that time come from?
- How do you roll out a new engine version without stopping trading?
From the lesson Design a stock exchange matching engine
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
On a day of big news, one instrument receives 40 % of all inputs. Its matching thread runs at 95 % while other threads are nearly idle, and its latency climbs. One order book cannot be matched by two threads. How do you keep up?
- What it tests
- Why one book has one writer, moving other books away, taking decoding, checks and logging off the matching thread, cheaper inputs, per-session limits, and a utilisation target worked out from queueing.
- First step
- Work out what 95 % means for waiting: with random arrivals, the queue in front of the thread grows like u ÷ (1 − u), so latency climbs long before throughput stops. Then split the thread's work into what must stay, matching this one book, and what can move: other books, decoding, checks, logging and publishing.
- Follow-ups
-
- Why not give the hot book two threads that share it under a lock?
- How many inputs a second can the thread take if each costs 4 microseconds?
- One member sends half of the hot book's inputs. What changes?
From the lesson Design a stock exchange matching engine
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
During a volatile hour, a market data subscriber connected over TCP falls 30 seconds behind. The publisher keeps every unsent message in memory, memory grows, and the matching engine starts to stall. Explain how one slow subscriber reached the engine, and redesign the feed so that no subscriber can.
- What it tests
- Decoupling the engine from publishing, bounded buffers per subscriber, recovery by snapshot and replay, sequenced multicast with gap requests, and conflated feeds for screens.
- First step
- Trace the path from the engine to the socket and mark every place that can wait. If the engine hands events to the publisher in a way that can block, or the publisher's memory is shared and unbounded, a full socket at one subscriber becomes back pressure on the engine. The rule to aim for: the engine writes once and never waits for any reader.
- Follow-ups
-
- How does the disconnected subscriber catch up?
- Thousands of screens need prices, not every order. What do they get?
- Packets are lost on a multicast feed. Who repairs the gap?
From the lesson Design a stock exchange matching engine
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
-
Mid to senior
Your app showed an order as open after it had been completely filled: the exchange's fill report reached the order service before its acknowledgement, and the acknowledgement was applied last. Support also finds clients whose positions count one fill twice. Redesign how exchange reports are applied so that neither can happen.
- What it tests
- Applying asynchronous reports by merging rather than copying: report ids against duplicates, quantities that never fall, final states, one writer per order, and what the client sees meanwhile.
- First step
- Stop treating each report as the new truth. A report says what the exchange knew when it sent it, so ask which values can only grow, such as the filled quantity and the set of fills already applied, and which states can never be undone. Then apply each report by merging it into what the order service already knows.
- Follow-ups
-
- Two reports for the same order are applied by two workers at once. What goes wrong?
- The cumulative quantity says the order is complete, but one fill's details are missing.
- A cancel request and the final fill cross at the exchange.
From the lesson Design broker order management like Zerodha
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Senior to staff
At the market open your order traffic jumps tenfold within ten seconds. The exchange gateways queue orders for several seconds, clients tap buy again, and some of the duplicate orders fill. Design the order path for the open, from the app to the exchange sessions.
- What it tests
- Capacity that has to be arranged in advance, priority for cancels, a key per tap, refusing early instead of queueing long, per-client limits, and honest states in the app.
- First step
- Find the hard limit first: each exchange session carries a fixed number of messages a second, and sessions are arranged before the open, so the order path's capacity at the open is decided beforehand. Compare it with the burst, then decide what happens to the excess: it waits, it is refused, or it goes first.
- Follow-ups
-
- Why should cancels go before new orders?
- A client taps buy three times in two seconds. What reaches the exchange?
- How long may an order wait before refusing it is better?
From the lesson Design broker order management like Zerodha
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
A client with funds for one order placed two orders from two devices within the same millisecond, and both passed the funds check and filled. Explain the race, and design the risk check so that funds are never used twice, without one global lock for all clients.
- What it tests
- Check-then-act races, blocking funds atomically per client, one writer per client or a conditional update, releasing blocks on rejects and cancels, and keeping the check fast at the open.
- First step
- Write down what each order did: it read the available funds, compared them with what it needed, and blocked them later. Both reads happened before either block, so both saw enough. The check and the block have to become one step for each client.
- Follow-ups
-
- Where do the funds go when the exchange rejects the order?
- How do you keep the check fast at 20,000 orders a second?
- What changes for a sell of shares the client holds?
From the lesson Design broker order management like Zerodha
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
All System Design (High-Level Design) interview questions · The System Design (High-Level Design) track