System Design Interview
UPI payment app inspired by PhonePe and Google Pay on NPCI's UPI network: a transaction saved as pending under an idempotency key before money moves, switch calls from a queue with timeouts, status served from a cache, UPI ID name lookup, push and SMS notifications, daily reconciliation against NPCI settlement files, and pre-payment risk checks. A teaching design.
See why saving a payment only after it completes loses money and double-charges.
What was missing: Nothing yet.
Why that's risky: If the server crashes after the payer's bank debits but before the save, the app has no record of the payment. If the user taps Pay again after a timeout, it's charged twice. Every request holds a thread for the whole bank round trip.
What gets added: One server that calls NPCI's UPI switch for each payment, waits for the answer, then saves the transaction.
Trade-offs: Simple and synchronous, but the database learns about the money last.
Make every payment exist before money moves, and make retries safe.
What was missing: A payment existed only after it finished, and retries made new payments.
Why that's risky: The payment service still waits on the bank round trip, and a slow bank ties up its threads. Status checks hit the database directly.
What gets added: The payment service saves each transaction as pending, under the client's idempotency key, before calling the switch. A retry with the same key finds the existing transaction. Status moves forward only (pending to success, failed or deemed) through conditional updates. A status service answers "did it go through?".
Trade-offs: One extra write per payment buys a record of every attempt.
Stop slow banks from blocking the app, and answer status and name lookups from memory.
What was missing: Payment requests waited on banks, and every status check read the database.
Why that's risky: Nobody is told when a payment completes, and nothing catches transactions stuck in pending if the switch never answered.
What gets added: The payment service saves the pending transaction, queues it and returns. Switch workers call NPCI with a timeout and record the result in the database and a status cache. The app polls status from the cache. A VPA service resolves a UPI ID or QR code to the payee's verified name from a cache before the user confirms.
Trade-offs: The app shows "processing" for a second or two instead of blocking, which is what UPI apps actually do.
Tell both sides what happened, and make sure every rupee matches NPCI's books by the end of the day.
What was missing: No notifications, and no check that the app's records match the money that actually moved.
Why that's risky: No fraud screening, no per-user limits, and one load balancer in front of everything.
What gets added: Completed and failed payments go onto an events queue. A notification worker sends push and SMS to payer and payee. A reconciliation worker matches every transaction against NPCI's settlement files and resolves anything pending or mismatched with a credit or an automatic reversal, within NPCI's deadlines.
Trade-offs: Reconciliation runs in batches, so a stuck payment can take hours to resolve. That's why UPI apps say "money will be refunded within 48 hours".
Block fraud before money moves, and see a failing bank before users flood support.
What was missing: Fraud was found only after money moved, and a bank outage showed up as angry users rather than an alert.
Why that's risky: Remaining risk is low. A bank-wide outage still fails its payments, but the app can warn users before they try.
What gets added: A risk service that scores each payment from recent activity per device, account and payee, and blocks it or asks for extra checks. A rate limiter with per-user daily caps. A second load balancer, a replicated transactions database, and monitoring of success rate per bank, switch timeouts and pending counts.
Trade-offs: Risk scoring adds a few milliseconds to every payment, and a small share of genuine payments get extra checks.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
