Design UPI (Unified Payments Interface)

Advanced Payments & fintech

The problem

Design a real-time payment system like UPI. A person pays another person or a shop from their bank account to the other's, using only a virtual address or a QR code.

You are in a 45-minute interview. The interviewer cares about correctness and failure handling more than boxes.

Many apps (PSPs) and many banks connect through a central switch.

Think about paying for tea by scanning a QR code.

You are given

About 15 billion transactions a month.
Peak traffic is about 3 times the average.
Each transaction writes about 2 ledger entries of 200 bytes.
A payment should complete within a few seconds.

What we expect from you

Drive the conversation. Ask questions before drawing anything. State your assumptions out loud so they can be corrected early.
Use numbers. Turn the givens into requests per second, storage and bandwidth. Every later choice should point back to one of them.
Start simple, then evolve. Get a working version on the board first. Add caches, sharding and queues only when a number or a requirement asks for them.
Go deep on the hard parts. For this problem the hard parts are idempotency, consistency across two banks, handling timeouts, and an auditable ledger.
Name the trade-offs. Say what you chose, what you gave up, and what would make you change your mind.
Think about failure. Point out single points of failure and say what happens when a node, a cache or a whole zone goes down.

Scope

In scope

Pay, collect, status and reversal
Routing between banks via a switch
Idempotency, ledger and failure handling
Fraud controls and scale

Not required

Building the mobile app UI
Regulatory process details
Merchant onboarding

Suggested time

Clarify requirements	4 min
Estimate scale	4 min
API and data model	5 min
High-level design	7 min
Deep dive	15 min
Reliability	5 min
Trade-offs and wrap-up	5 min

What makes an answer great

Makes the transaction id an idempotency key at every hop.
Uses a saga with reversals, not a cross-bank transaction.
Treats a timeout as unknown, not as failure.
Keeps an append-only double-entry ledger and reconciliation.

Key concepts

VPA

Virtual payment address such as name@bank, so you do not share account numbers.

PSP

Payment service provider: the app and bank behind the app that connects users to the switch.

Switch

The central system that routes requests between banks and records results.

Saga

A series of local steps with compensating actions to undo them, used instead of a distributed transaction.

Idempotency key

A unique id that makes repeating a request safe.

Reconciliation

Comparing two systems' records to find and fix differences.

Double-entry ledger

Every transfer records equal debit and credit entries, so the books always balance.

Numbers worth remembering

15B per month = about 500M a day = 5,800/s average, 17,000/s peak
Ledger: 500M x 2 x 200 B = 200 GB a day, about 73 TB a year
Availability target: 99.99% is under 53 minutes of downtime a year

Locked in so far

Decisions you confirm will collect here as you go.

Your design so far