Bonus Problem 1: India's UPI
The World's Largest Real-Time Payment System
🇮🇳 A Revolution That Changed a Nation
In 2016, India launched an experiment. Could a country of 1.4 billion people, many unbanked, leapfrog decades of payment infrastructure and go directly to real-time digital payments?
Eight years later, the answer is extraordinary.
THE NUMBERS THAT DEFINE UPI (2025)
┌──────────────────────────────────────────────────────────────────────────┐
│ │
│ DAILY TRANSACTIONS MONTHLY TRANSACTIONS │
│ ──────────────────── ──────────────────── │
│ 640+ Million 20+ Billion │
│ │
│ ANNUAL TRANSACTIONS ANNUAL VALUE │
│ ─────────────────── ──────────── │
│ 250+ Billion $3.4+ Trillion (₹247 Lakh Crore) │
│ │
│ PARTICIPATING BANKS ACTIVE USERS │
│ ────────────────── ──────────── │
│ 680+ 500+ Million │
│ │
│ AVERAGE LATENCY SUCCESS RATE │
│ ─────────────── ──────────── │
│ ~270 milliseconds 99.2% │
│ │
│ GLOBAL SHARE COUNTRIES ACCEPTING UPI │
│ ──────────── ───────────────────── │
│ 50% of world's 8+ (Singapore, UAE, France, │
│ digital transactions Nepal, Bhutan, Sri Lanka...) │
│ │
└──────────────────────────────────────────────────────────────────────────┘
For context:
• UPI processes MORE transactions than Visa and Mastercard COMBINED in India
• A tea vendor in rural India uses the same system as a Fortune 500 company
• Transactions as small as ₹1 (1 cent) work with the same reliability as ₹1 Crore
• The system operates 24/7/365 with no maintenance windows
This is the system we'll design today.
The Interview Begins
You're interviewing at a fintech company. The principal architect draws on the whiteboard:
Interviewer: "India's UPI is considered one of the greatest achievements in financial technology. Countries around the world are trying to replicate it. Today, I want you to design a system like UPI from scratch."
╔══════════════════════════════════════════════════════════════════════════╗
║ ║
║ Design a Real-Time Inter-Bank Payment System ║
║ ║
║ Build the infrastructure that enables instant money transfers ║
║ between ANY two bank accounts in a country using just a phone. ║
║ ║
║ Requirements: ║
║ • Support 500+ banks with different legacy systems ║
║ • Handle 600+ million transactions per day ║
║ • Complete each transaction in < 2 seconds end-to-end ║
║ • 99.9% availability (< 9 hours downtime/year) ║
║ • Zero tolerance for money loss (atomic transactions) ║
║ • Work on basic smartphones with 2G/3G connectivity ║
║ • Support both P2P (person-to-person) and P2M (person-to-merchant) ║
║ ║
╚══════════════════════════════════════════════════════════════════════════╝
Interviewer: "This is arguably one of the hardest system design problems — you're building financial infrastructure for a nation. Take your time."
Phase 1: Requirements Clarification
You: "Before I start, let me understand the constraints better."
Your Questions
You: "First, what's the relationship between banks and this central system? Do banks connect directly, or through intermediaries?"
Interviewer: "Banks connect through the central switch — NPCI in India's case. They don't talk to each other directly. The central system orchestrates everything."
You: "What about the mobile apps? Can any app connect to the system?"
Interviewer: "Apps must be approved and must partner with a bank. We call these Payment Service Providers or PSPs. PhonePe partners with Yes Bank, Google Pay with multiple banks. The app itself doesn't hold money — it's just an interface."
You: "How do users identify each other? Bank account numbers are long and error-prone."
Interviewer: "Great observation. UPI solved this with Virtual Payment Addresses — like an email for money. username@bankname. The system maps this to actual bank accounts."
You: "What happens if a transaction fails mid-way? Say money is debited but not credited?"
Interviewer: "This is critical. The system MUST be atomic. Either the full transaction succeeds, or it's completely rolled back. Users cannot lose money due to technical failures."
You: "What's the peak traffic pattern? Is it bursty?"
Interviewer: "Very bursty. Evening hours see 2-3x average traffic. Festival seasons like Diwali can see 5x normal load. The system must handle these gracefully."
Requirements Summary
Functional Requirements:
1. USER MANAGEMENT
• Register users via mobile number + bank account
• Create and manage Virtual Payment Addresses (VPAs)
• Link multiple bank accounts to one app
• Two-factor authentication (device binding + PIN)
2. PAYMENT OPERATIONS
• Push payments (I send money to you)
• Pull payments / Collect requests (I request money from you)
• QR code payments (scan and pay)
• Recurring payments (autopay/mandates)
3. TRANSACTION PROCESSING
• Real-time debit from sender's bank
• Real-time credit to receiver's bank
• Transaction status tracking
• Refund/reversal handling
4. BANK INTEGRATION
• Standardized APIs for all banks
• VPA to account resolution
• Balance inquiry (with consent)
• Account validation
5. SETTLEMENT
• Net settlement between banks (periodic)
• Reconciliation and dispute handling
• Audit trail for compliance
Non-Functional Requirements:
SCALE
• 600+ million transactions/day
• 20+ billion transactions/month
• 500+ million active users
• 680+ participating banks
LATENCY
• End-to-end: < 2 seconds (p99)
• NPCI switch processing: < 300ms
• Bank response time: < 1 second
AVAILABILITY
• 99.9% uptime (8.7 hours downtime/year max)
• 24/7/365 operation
• No scheduled maintenance windows
CONSISTENCY
• ACID transactions (money can't be lost)
• Exactly-once semantics
• Atomic debit-credit operations
SECURITY
• End-to-end encryption
• Device binding
• Multi-factor authentication
• Fraud detection in real-time
Phase 2: Back of the Envelope Estimation
You: "Let me work through the numbers..."
Traffic Calculations
TRANSACTIONS PER SECOND
Daily transactions: 640,000,000
Seconds per day: 86,400
Average TPS: ~7,400 TPS
Peak multiplier: 3-5x (evenings, festivals)
Peak TPS: ~25,000-35,000 TPS
Per transaction, multiple operations:
├── VPA resolution: 1 lookup
├── Sender bank call: 1 API call
├── Receiver bank call: 1 API call
├── Audit logging: 1-2 writes
└── Notifications: 2 pushes
Effective operations/second: ~150,000+ at peak
Data Volume
STORAGE REQUIREMENTS
Per transaction record:
├── Transaction ID: 36 bytes (UUID)
├── Sender VPA: 50 bytes
├── Receiver VPA: 50 bytes
├── Amount: 8 bytes
├── Timestamps: 16 bytes
├── Status: 4 bytes
├── Bank references: 100 bytes
├── Metadata: 200 bytes
└── Total: ~500 bytes
Daily storage:
├── Transactions: 640M × 500B = 320 GB/day
├── Audit logs: ~500 GB/day
└── Total: ~800 GB/day
Annual storage: ~300 TB/year
7-year retention: ~2 PB
Infrastructure Estimates
COMPUTE REQUIREMENTS
At 25,000 TPS peak, assuming each server handles 1,000 TPS:
├── API servers: 25+ servers (with redundancy: 50+)
├── Database: Clustered, sharded
├── Cache: Distributed Redis cluster
└── Message queues: High-throughput Kafka cluster
NETWORK
├── Connections to 680+ banks
├── Each bank: dedicated secure link
├── Geographic distribution: Multiple data centers
└── Bandwidth: Several Gbps
Phase 3: High-Level Architecture
You: "Let me draw how UPI actually works. It's a beautiful layered architecture."
The Three-Layer Cake
UPI ARCHITECTURE: THE THREE-LAYER CAKE
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ LAYER 1: USER INTERFACE │
│ ─────────────────────── │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ PhonePe │ │ Google Pay │ │ Paytm │ │ BHIM │ │
│ │ (App) │ │ (App) │ │ (App) │ │ (App) │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │ │
│ └────────────────┼────────────────┼────────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ PSP (Payment Service Providers) │ │
│ │ │ │
│ │ Apps must partner with a bank (PSP Bank) to access UPI │ │
│ │ PhonePe → Yes Bank Google Pay → Multiple banks │ │
│ │ The PSP handles: User onboarding, VPA creation, UI/UX │ │
│ └──────────────────────────────┬──────────────────────────────────┘ │
│ │ │
└───────────────────────────────────┼─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ LAYER 2: NPCI SWITCH │
│ ──────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ NPCI UPI PLATFORM │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ VPA │ │ Transaction │ │ Fraud │ │ │
│ │ │ Mapper │ │ Router │ │ Detection │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Settlement │ │ Audit │ │ Dispute │ │ │
│ │ │ Engine │ │ Trail │ │ Resolution │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ │ The brain of UPI: Routes transactions between banks │ │
│ │ NPCI NEVER holds money — only routes information │ │
│ └──────────────────────────────┬──────────────────────────────────┘ │
│ │ │
└───────────────────────────────────┼─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ LAYER 3: BANKING LAYER │
│ ────────────────────── │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ SBI │ │ HDFC │ │ ICICI │ │ Axis │ │ 680+ │ │
│ │ Bank │ │ Bank │ │ Bank │ │ Bank │ │ Banks │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │ │ │
│ └───────────┴───────────┴───────────┴───────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ IMPS (Immediate Payment Service) │ │
│ │ │ │
│ │ The settlement rail that actually moves money between banks │ │
│ │ UPI transactions settle via IMPS under the hood │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
KEY INSIGHT:
• Money flows: Bank → Bank (through IMPS)
• Information flows: App → PSP → NPCI → Banks
• NPCI is the orchestrator, not a money holder
Transaction Flow
You: "Let me trace a ₹500 payment from Alice to Bob..."
TRANSACTION FLOW: ALICE PAYS BOB ₹500
Alice's Phone NPCI Banks
(PhonePe App) Switch
│ │ │
│ ① INITIATE │ │
│ ─────────────────────▶│ │
│ "Pay ₹500 to │ │
│ bob@okaxis" │ │
│ + Alice's VPA │ │
│ + Encrypted PIN │ │
│ │ │
│ │ ② RESOLVE VPA │
│ │ ─────────────────────▶│
│ │ "Who is bob@okaxis?" │
│ │ │
│ │ ③ VPA RESPONSE │
│ │◀───────────────────── │
│ │ "Bob's account at │
│ │ Axis Bank: XXXX1234" │
│ │ │
│ │ ④ DEBIT REQUEST │
│ │ ─────────────────────▶│
│ │ "Debit ₹500 from │ HDFC
│ │ Alice at HDFC" │ (Alice's Bank)
│ │ │
│ │ ⑤ DEBIT RESPONSE │
│ │◀───────────────────── │
│ │ "Debited. Ref: ABC123"│
│ │ │
│ │ ⑥ CREDIT REQUEST │
│ │ ─────────────────────▶│
│ │ "Credit ₹500 to │ AXIS
│ │ Bob at Axis" │ (Bob's Bank)
│ │ │
│ │ ⑦ CREDIT RESPONSE │
│ │◀───────────────────── │
│ │ "Credited. Ref: XYZ789"│
│ │ │
│ ⑧ SUCCESS │ │
│◀───────────────────── │ │
│ "Payment complete! │ │
│ Ref: TXN123456" │ │
│ │ │
▼ ▼ ▼
TOTAL TIME: < 2 seconds
PARALLEL ACTIONS:
• Audit log written at each step
• Fraud check runs during step ①
• Push notifications sent to both Alice and Bob
• Settlement record created for bank reconciliation
Phase 4: Deep Dives
Deep Dive 1: Virtual Payment Address (VPA) Resolution
Week 1 concepts: Partitioning, lookup optimization. Week 4 concepts: Caching.
You: "VPA resolution is called for EVERY transaction. With 640 million daily transactions, this lookup must be blazing fast."
The Challenge:
VPA RESOLUTION CHALLENGE
500+ million VPAs like:
├── alice@okhdfc
├── bob@okaxis
├── merchant@paytm
├── 9876543210@ybl
└── ...
Each VPA maps to:
├── Bank code
├── Account number (encrypted)
├── Account holder name
├── Status (active/blocked)
└── Metadata
Requirements:
├── Lookup latency: < 10ms
├── 100% accuracy (wrong mapping = money to wrong person!)
├── Real-time updates (user changes bank)
└── Handle 50,000+ lookups/second at peak
The Solution:
VPA MAPPER ARCHITECTURE
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ VPA RESOLUTION FLOW │
│ │
│ │
│ VPA: bob@okaxis │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ PARSE HANDLE │ Extract: handle="bob", suffix="okaxis" │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ SUFFIX LOOKUP │────▶│ BANK REGISTRY │ │
│ │ │ │ │ │
│ │ "okaxis" → Axis │ │ okhdfc → HDFC │ │
│ │ Bank Code │ │ okaxis → Axis │ │
│ └────────┬────────┘ │ paytm → Paytm │ │
│ │ │ ybl → Yes Bank │ │
│ │ └─────────────────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ CACHE CHECK │ │
│ │ (Redis) │ │
│ └────────┬────────┘ │
│ │ │
│ Cache Hit? │
│ │ │ │
│ Yes No │
│ │ │ │
│ │ ▼ │
│ │ ┌─────────────────┐ ┌─────────────────┐ │
│ │ │ QUERY BANK │────▶│ Axis Bank │ │
│ │ │ (Real-time) │ │ VPA Database │ │
│ │ └────────┬────────┘ └─────────────────┘ │
│ │ │ │
│ │ │ Update cache │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────┐ │
│ │ RETURN ACCOUNT │ │
│ │ DETAILS │ │
│ │ │ │
│ │ Bank: Axis │ │
│ │ Account: ***234 │ │
│ │ Name: Bob Kumar │ │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
KEY DESIGN DECISIONS:
1. DISTRIBUTED OWNERSHIP
Each bank owns their VPA namespace (suffix)
NPCI doesn't store all VPAs — banks do
This scales naturally as banks handle their own data
2. CACHING STRATEGY
Hot VPAs (frequently used) cached at NPCI
TTL: 15-30 minutes
Invalidation: Banks push updates for VPA changes
3. HANDLE UNIQUENESS
handle@suffix is globally unique
Banks ensure uniqueness within their namespace
Cross-bank uniqueness handled by suffix differentiation
# vpa/resolver.py
"""
VPA Resolution Service
Maps Virtual Payment Addresses to actual bank accounts.
This is the most critical lookup in the entire system.
"""
from dataclasses import dataclass
from typing import Optional, Tuple
from datetime import datetime, timedelta
import hashlib
@dataclass
class AccountDetails:
"""Resolved account information."""
bank_code: str
account_number_masked: str # Only last 4 digits visible
account_holder_name: str
ifsc_code: str
is_active: bool
verified_at: datetime
@dataclass
class VPAResolutionResult:
"""Result of VPA resolution."""
success: bool
account: Optional[AccountDetails] = None
error_code: Optional[str] = None
resolution_time_ms: float = 0
cache_hit: bool = False
class VPAResolver:
"""
Resolves VPAs to bank account details.
Design principles:
- Cache aggressively (VPAs don't change often)
- Fail fast on invalid formats
- Banks are the source of truth
"""
def __init__(
self,
cache, # Redis cluster
bank_registry, # Bank code → Bank API mapping
bank_gateway, # Gateway to call bank APIs
metrics
):
self.cache = cache
self.registry = bank_registry
self.gateway = bank_gateway
self.metrics = metrics
# Cache settings
self.cache_ttl = timedelta(minutes=30)
self.negative_cache_ttl = timedelta(minutes=5)
async def resolve(self, vpa: str) -> VPAResolutionResult:
"""
Resolve a VPA to account details.
VPA format: handle@suffix
Example: alice@okhdfc, 9876543210@ybl
"""
start_time = datetime.utcnow()
# Step 1: Parse and validate VPA format
parsed = self._parse_vpa(vpa)
if not parsed:
return VPAResolutionResult(
success=False,
error_code="INVALID_VPA_FORMAT"
)
handle, suffix = parsed
# Step 2: Get bank code from suffix
bank_code = self.registry.get_bank_for_suffix(suffix)
if not bank_code:
return VPAResolutionResult(
success=False,
error_code="UNKNOWN_VPA_SUFFIX"
)
# Step 3: Check cache
cache_key = f"vpa:{vpa.lower()}"
cached = await self.cache.get(cache_key)
if cached:
if cached == "NOT_FOUND":
return VPAResolutionResult(
success=False,
error_code="VPA_NOT_FOUND",
cache_hit=True
)
account = AccountDetails(**cached)
return VPAResolutionResult(
success=True,
account=account,
resolution_time_ms=self._elapsed_ms(start_time),
cache_hit=True
)
# Step 4: Query the bank
try:
account = await self.gateway.resolve_vpa(
bank_code=bank_code,
handle=handle,
suffix=suffix
)
if account:
# Cache the result
await self.cache.set(
cache_key,
account.__dict__,
ttl=self.cache_ttl
)
return VPAResolutionResult(
success=True,
account=account,
resolution_time_ms=self._elapsed_ms(start_time),
cache_hit=False
)
else:
# Cache negative result (VPA doesn't exist)
await self.cache.set(
cache_key,
"NOT_FOUND",
ttl=self.negative_cache_ttl
)
return VPAResolutionResult(
success=False,
error_code="VPA_NOT_FOUND",
resolution_time_ms=self._elapsed_ms(start_time)
)
except BankTimeoutError:
return VPAResolutionResult(
success=False,
error_code="BANK_TIMEOUT"
)
except BankUnavailableError:
return VPAResolutionResult(
success=False,
error_code="BANK_UNAVAILABLE"
)
def _parse_vpa(self, vpa: str) -> Optional[Tuple[str, str]]:
"""Parse VPA into handle and suffix."""
if not vpa or '@' not in vpa:
return None
parts = vpa.lower().strip().split('@')
if len(parts) != 2:
return None
handle, suffix = parts
# Validate handle (alphanumeric, 3-50 chars)
if not handle or len(handle) < 3 or len(handle) > 50:
return None
# Validate suffix (registered bank suffix)
if not suffix or len(suffix) < 2 or len(suffix) > 20:
return None
return handle, suffix
def _elapsed_ms(self, start: datetime) -> float:
return (datetime.utcnow() - start).total_seconds() * 1000
Deep Dive 2: Atomic Transactions — The Heart of Trust
Week 2 concepts: Idempotency, failure handling. Week 5 concepts: Distributed transactions, Saga pattern.
You: "The most critical requirement: money cannot disappear. If I debit Alice but fail to credit Bob, Alice must get her money back. Always."
The Challenge:
THE ATOMICITY CHALLENGE
Happy path:
① Debit Alice (HDFC): ₹500 ✓
② Credit Bob (Axis): ₹500 ✓
→ Success!
Failure scenarios:
SCENARIO A: Credit fails after debit
① Debit Alice: ₹500 ✓ (money left Alice's account)
② Credit Bob: TIMEOUT ✗ (did it go through or not?)
→ UNCERTAINTY! Alice lost ₹500?
SCENARIO B: Network partition
① Debit Alice: ✓
② Credit Bob: Request sent...
③ Network dies
④ We don't know the outcome!
→ UNCERTAINTY!
SCENARIO C: Duplicate request
① User clicks "Pay" twice quickly
② Two debit requests sent
→ DOUBLE DEBIT! Alice loses ₹1000?
These scenarios CANNOT happen in a payment system.
The Solution:
UPI'S TRANSACTION STATE MACHINE
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ TRANSACTION STATE MACHINE │
│ │
│ │
│ ┌──────────────┐ │
│ │ CREATED │ │
│ │ │ │
│ └──────┬───────┘ │
│ │ │
│ │ Validation passed │
│ ▼ │
│ ┌──────────────┐ │
│ │ PENDING │ │
│ │ │ │
│ └──────┬───────┘ │
│ │ │
│ │ Send to remitter bank │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ FAILED │◀─────│ DEBIT │─────▶│ DEBITED │ │
│ │ │ │ INITIATED │ │ │ │
│ │ (No debit │ │ │ │ (Money left │ │
│ │ happened) │ └──────────────┘ │ sender) │ │
│ └──────────────┘ └──────┬───────┘ │
│ │ │
│ │ Send to │
│ │ beneficiary bank │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ REVERSED │◀─────│ CREDIT │─────▶│ COMPLETED │ │
│ │ │ │ INITIATED │ │ │ │
│ │ (Money back │ │ │ │ (Money │ │
│ │ to sender) │ └──────────────┘ │ received) │ │
│ └──────────────┘ │ └──────────────┘ │
│ ▲ │ │
│ │ │ Credit timeout/failure │
│ │ ▼ │
│ │ ┌──────────────┐ │
│ └──────────────│ DEEMED │ │
│ Auto-reverse │ SUCCESS │ │
│ after T+2 │ │ │
│ │ (Uncertain │ │
│ │ state) │ │
│ └──────────────┘ │
│ │
│ DEEMED SUCCESS: Bank didn't respond in time. │
│ Settlement happens, if credit actually failed, auto-reversal at T+2 │
│ │
└─────────────────────────────────────────────────────────────────────────┘
# transaction/processor.py
"""
Transaction Processing with Atomic Guarantees.
This is the most critical code in the entire system.
Money cannot be lost under any circumstances.
"""
from dataclasses import dataclass
from typing import Optional
from enum import Enum
from datetime import datetime, timedelta
import uuid
class TransactionState(Enum):
CREATED = "created"
PENDING = "pending"
DEBIT_INITIATED = "debit_initiated"
DEBITED = "debited"
CREDIT_INITIATED = "credit_initiated"
COMPLETED = "completed"
FAILED = "failed"
DEEMED_SUCCESS = "deemed_success"
REVERSED = "reversed"
@dataclass
class Transaction:
"""A UPI transaction record."""
txn_id: str
sender_vpa: str
receiver_vpa: str
amount: int # In paise (smallest unit)
state: TransactionState
created_at: datetime
updated_at: datetime
# Bank references
sender_bank_ref: Optional[str] = None
receiver_bank_ref: Optional[str] = None
# For idempotency
idempotency_key: Optional[str] = None
# Reversal tracking
reversal_initiated: bool = False
reversal_completed: bool = False
class TransactionProcessor:
"""
Processes UPI transactions with atomic guarantees.
Key principles:
1. IDEMPOTENCY: Same request = same result (no double-debit)
2. ATOMICITY: Either complete success or complete rollback
3. DURABILITY: State persisted before any bank call
4. RECOVERABILITY: Can resume from any failure point
"""
def __init__(
self,
db, # Transaction database
bank_gateway, # Bank API gateway
reversal_queue, # Queue for failed transactions
audit_log
):
self.db = db
self.gateway = bank_gateway
self.reversal_queue = reversal_queue
self.audit = audit_log
# Timeouts
self.debit_timeout = timedelta(seconds=30)
self.credit_timeout = timedelta(seconds=30)
async def process(
self,
sender_vpa: str,
receiver_vpa: str,
amount: int,
idempotency_key: str
) -> Transaction:
"""
Process a payment transaction.
CRITICAL: This method must be idempotent.
Same idempotency_key = same result, always.
"""
# STEP 0: Check idempotency
existing = await self.db.get_by_idempotency_key(idempotency_key)
if existing:
# Return existing result (no reprocessing)
await self.audit.log("IDEMPOTENT_RETURN", existing.txn_id)
return existing
# STEP 1: Create transaction record FIRST
txn = Transaction(
txn_id=str(uuid.uuid4()),
sender_vpa=sender_vpa,
receiver_vpa=receiver_vpa,
amount=amount,
state=TransactionState.CREATED,
created_at=datetime.utcnow(),
updated_at=datetime.utcnow(),
idempotency_key=idempotency_key
)
# Persist BEFORE any bank call
await self.db.save(txn)
await self.audit.log("TXN_CREATED", txn.txn_id)
try:
# STEP 2: Initiate debit
txn.state = TransactionState.DEBIT_INITIATED
txn.updated_at = datetime.utcnow()
await self.db.save(txn)
debit_result = await self.gateway.debit(
vpa=sender_vpa,
amount=amount,
txn_ref=txn.txn_id,
timeout=self.debit_timeout
)
if not debit_result.success:
# Debit failed cleanly — no money moved
txn.state = TransactionState.FAILED
txn.updated_at = datetime.utcnow()
await self.db.save(txn)
await self.audit.log("DEBIT_FAILED", txn.txn_id,
debit_result.error)
return txn
# STEP 3: Debit succeeded — record it
txn.state = TransactionState.DEBITED
txn.sender_bank_ref = debit_result.bank_reference
txn.updated_at = datetime.utcnow()
await self.db.save(txn)
await self.audit.log("DEBIT_SUCCESS", txn.txn_id)
# STEP 4: Initiate credit
# CRITICAL: From this point, we MUST either complete or reverse
txn.state = TransactionState.CREDIT_INITIATED
txn.updated_at = datetime.utcnow()
await self.db.save(txn)
credit_result = await self.gateway.credit(
vpa=receiver_vpa,
amount=amount,
txn_ref=txn.txn_id,
timeout=self.credit_timeout
)
if credit_result.success:
# SUCCESS! Transaction complete
txn.state = TransactionState.COMPLETED
txn.receiver_bank_ref = credit_result.bank_reference
txn.updated_at = datetime.utcnow()
await self.db.save(txn)
await self.audit.log("TXN_COMPLETED", txn.txn_id)
return txn
elif credit_result.status == "TIMEOUT":
# UNCERTAINTY: We don't know if credit happened
# Mark as DEEMED_SUCCESS — settlement will clarify
txn.state = TransactionState.DEEMED_SUCCESS
txn.updated_at = datetime.utcnow()
await self.db.save(txn)
await self.audit.log("TXN_DEEMED_SUCCESS", txn.txn_id)
# Schedule reconciliation check
await self.reversal_queue.schedule_check(
txn.txn_id,
check_at=datetime.utcnow() + timedelta(hours=24)
)
return txn
else:
# Credit FAILED — must reverse the debit
await self._initiate_reversal(txn)
return txn
except Exception as e:
# Unexpected error — check state and recover
await self.audit.log("TXN_ERROR", txn.txn_id, str(e))
await self._handle_error(txn, e)
raise
async def _initiate_reversal(self, txn: Transaction):
"""
Reverse a failed transaction.
Credit the debited amount back to sender.
"""
txn.reversal_initiated = True
txn.updated_at = datetime.utcnow()
await self.db.save(txn)
await self.audit.log("REVERSAL_INITIATED", txn.txn_id)
# Queue for reversal (handled by separate process)
await self.reversal_queue.enqueue(txn.txn_id)
async def process_reversal(self, txn_id: str):
"""
Execute reversal — credit money back to sender.
Called by reversal worker.
"""
txn = await self.db.get(txn_id)
if txn.reversal_completed:
return # Already reversed
# Credit back to sender
reversal_result = await self.gateway.credit(
vpa=txn.sender_vpa,
amount=txn.amount,
txn_ref=f"REV-{txn.txn_id}",
timeout=self.credit_timeout
)
if reversal_result.success:
txn.state = TransactionState.REVERSED
txn.reversal_completed = True
txn.updated_at = datetime.utcnow()
await self.db.save(txn)
await self.audit.log("REVERSAL_COMPLETED", txn.txn_id)
else:
# Reversal failed — retry later
# This is a critical alert scenario
await self.audit.log("REVERSAL_FAILED", txn.txn_id,
reversal_result.error)
await self.reversal_queue.schedule_retry(
txn.txn_id,
retry_at=datetime.utcnow() + timedelta(minutes=15)
)
Interviewer: "What about the 'deemed success' state? That seems risky."
You: "Great catch. Here's how reconciliation handles it..."
DEEMED SUCCESS RECONCILIATION
Scenario: We debited Alice, tried to credit Bob, got TIMEOUT
At NPCI level:
├── Transaction marked DEEMED_SUCCESS
├── We don't know if Bob got money
└── Settlement file sent to banks includes this transaction
At Bank level (T+1 reconciliation):
├── Bank compares settlement file with actual credits
├── If credit happened: Mark as COMPLETED
├── If credit NOT happened: Mark as FAILED → Auto-reversal
Timing:
├── T+0: Transaction happens, deemed success
├── T+1: Banks reconcile, report actual status
├── T+2: NPCI updates final status
├── T+2: If failed, reversal initiated automatically
This is why UPI guidelines say:
"If money is debited but not credited, it will be
automatically reversed within 5 business days"
In practice, it's usually resolved within 24-48 hours.
Deep Dive 3: Bank Integration at Scale
Week 2 concepts: Timeouts, circuit breakers. Week 3 concepts: Message queues.
You: "With 680+ banks, each with different legacy systems, bank integration is a massive challenge."
BANK INTEGRATION ARCHITECTURE
┌────────────────────────────────────────────────────────────────────────┐
│ │
│ NPCI → BANK GATEWAY │
│ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ BANK ADAPTER LAYER │ │
│ │ │ │
│ │ Every bank exposes standard UPI APIs, but internal │ │
│ │ implementations vary wildly. The adapter handles this. │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ SBI Adapter │ │ HDFC Adapter│ │ Axis Adapter│ ... │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ Handles: │ │ Handles: │ │ Handles: │ │ │
│ │ │ - SBI's │ │ - HDFC's │ │ - Axis's │ │ │
│ │ │ quirks │ │ quirks │ │ quirks │ │ │
│ │ │ - Retry │ │ - Retry │ │ - Retry │ │ │
│ │ │ logic │ │ logic │ │ logic │ │ │
│ │ │ - Timeouts │ │ - Timeouts │ │ - Timeouts │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │ │
│ │ └────────────────┼────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ CIRCUIT BREAKER LAYER │ │ │
│ │ │ │ │ │
│ │ │ Per-bank circuit breakers prevent cascade failures │ │ │
│ │ │ │ │ │
│ │ │ SBI: [CLOSED] ████████░░ (healthy) │ │ │
│ │ │ HDFC: [CLOSED] █████████░ (healthy) │ │ │
│ │ │ Axis: [OPEN] ░░░░░░░░░░ (failing, skip for 30s) │ │ │
│ │ │ ICICI: [HALF] █████░░░░░ (testing recovery) │ │ │
│ │ │ │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ SECURE COMMUNICATION LAYER │ │ │
│ │ │ │ │ │
│ │ │ - HTTPS with mutual TLS │ │ │
│ │ │ - Request/Response signing │ │ │
│ │ │ - Encryption of sensitive data │ │ │
│ │ │ - IP whitelisting │ │ │
│ │ │ - Dedicated leased lines to major banks │ │ │
│ │ │ │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
# bank/gateway.py
"""
Bank Gateway: Unified interface to 680+ banks.
Each bank is different. This gateway provides a
consistent interface while handling per-bank quirks.
"""
from dataclasses import dataclass
from typing import Dict, Optional
from datetime import datetime, timedelta
from enum import Enum
class CircuitState(Enum):
CLOSED = "closed" # Normal operation
OPEN = "open" # Bank failing, don't try
HALF_OPEN = "half" # Testing if bank recovered
@dataclass
class BankConfig:
"""Configuration for a bank."""
bank_code: str
endpoint: str
timeout_ms: int = 30000
# Circuit breaker settings
failure_threshold: int = 5
recovery_timeout_s: int = 30
# Bank-specific quirks
requires_padding: bool = False
amount_in_rupees: bool = False # Some banks want rupees, not paise
legacy_xml_format: bool = False
class BankGateway:
"""
Gateway for all bank operations.
"""
def __init__(
self,
http_client,
bank_configs: Dict[str, BankConfig],
metrics
):
self.http = http_client
self.configs = bank_configs
self.metrics = metrics
# Circuit breakers per bank
self.circuits: Dict[str, CircuitBreaker] = {
code: CircuitBreaker(config)
for code, config in bank_configs.items()
}
async def debit(
self,
bank_code: str,
account_ref: str,
amount: int,
txn_ref: str
) -> 'BankResponse':
"""
Debit an account at a bank.
Amount is in paise (smallest unit).
"""
config = self.configs.get(bank_code)
if not config:
return BankResponse(
success=False,
error_code="UNKNOWN_BANK"
)
# Check circuit breaker
circuit = self.circuits[bank_code]
if not circuit.can_execute():
self.metrics.increment("bank_circuit_open", bank_code)
return BankResponse(
success=False,
error_code="BANK_CIRCUIT_OPEN"
)
try:
# Build request (handle bank-specific formats)
request = self._build_debit_request(
config, account_ref, amount, txn_ref
)
# Make the call
start = datetime.utcnow()
response = await self.http.post(
config.endpoint + "/debit",
json=request,
timeout=config.timeout_ms / 1000
)
latency = (datetime.utcnow() - start).total_seconds() * 1000
# Record metrics
self.metrics.record_latency("bank_debit", bank_code, latency)
# Parse response
result = self._parse_response(config, response)
if result.success:
circuit.record_success()
else:
circuit.record_failure()
return result
except TimeoutError:
circuit.record_failure()
self.metrics.increment("bank_timeout", bank_code)
return BankResponse(
success=False,
error_code="TIMEOUT",
status="TIMEOUT"
)
except Exception as e:
circuit.record_failure()
self.metrics.increment("bank_error", bank_code)
return BankResponse(
success=False,
error_code="BANK_ERROR",
error_message=str(e)
)
def _build_debit_request(
self,
config: BankConfig,
account_ref: str,
amount: int,
txn_ref: str
) -> dict:
"""Build bank-specific request format."""
# Handle amount format (paise vs rupees)
if config.amount_in_rupees:
amount_value = amount / 100
else:
amount_value = amount
if config.legacy_xml_format:
# Some old banks still use XML
return {
"xml_payload": self._build_xml(
account_ref, amount_value, txn_ref
)
}
return {
"account_reference": account_ref,
"amount": amount_value,
"transaction_reference": txn_ref,
"timestamp": datetime.utcnow().isoformat()
}
class CircuitBreaker:
"""
Circuit breaker for bank connections.
Prevents cascade failures when a bank is down.
"""
def __init__(self, config: BankConfig):
self.config = config
self.state = CircuitState.CLOSED
self.failure_count = 0
self.last_failure: Optional[datetime] = None
self.success_count = 0
def can_execute(self) -> bool:
"""Check if we can make a request to this bank."""
if self.state == CircuitState.CLOSED:
return True
if self.state == CircuitState.OPEN:
# Check if recovery timeout passed
if self.last_failure:
elapsed = (datetime.utcnow() - self.last_failure).total_seconds()
if elapsed > self.config.recovery_timeout_s:
self.state = CircuitState.HALF_OPEN
self.success_count = 0
return True
return False
if self.state == CircuitState.HALF_OPEN:
return True
return False
def record_success(self):
"""Record a successful request."""
if self.state == CircuitState.HALF_OPEN:
self.success_count += 1
if self.success_count >= 3: # 3 successes to close
self.state = CircuitState.CLOSED
self.failure_count = 0
else:
self.failure_count = 0
def record_failure(self):
"""Record a failed request."""
self.failure_count += 1
self.last_failure = datetime.utcnow()
if self.state == CircuitState.HALF_OPEN:
# Back to open
self.state = CircuitState.OPEN
self.success_count = 0
elif self.failure_count >= self.config.failure_threshold:
self.state = CircuitState.OPEN
Deep Dive 4: Security — The Trust Foundation
Week 9 concepts: Security, authentication, fraud detection.
You: "UPI handles ₹20+ trillion monthly. Security isn't optional — it's existential."
UPI SECURITY ARCHITECTURE
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ MULTI-LAYER SECURITY │
│ │
│ LAYER 1: DEVICE BINDING │
│ ───────────────────────── │
│ • UPI PIN is bound to specific device │
│ • Device fingerprint (IMEI, hardware ID) │
│ • SIM binding (mobile number verification) │
│ • If device changes, re-registration required │
│ │
│ LAYER 2: TWO-FACTOR AUTHENTICATION │
│ ──────────────────────────────────── │
│ Factor 1: Something you HAVE │
│ • The registered mobile device │
│ • The SIM card with registered number │
│ │
│ Factor 2: Something you KNOW │
│ • 4-6 digit UPI PIN (set by user) │
│ • PIN encrypted on device, never transmitted in clear │
│ │
│ LAYER 3: ENCRYPTION │
│ ───────────────────── │
│ • HTTPS/TLS for all communication │
│ • UPI PIN encrypted using PBKDF2 (600,000 iterations) │
│ • PIN verification in bank's HSM (Hardware Security Module) │
│ • End-to-end encryption for sensitive data │
│ │
│ LAYER 4: TRANSACTION SIGNING │
│ ──────────────────────────── │
│ • Each transaction signed with digital signature │
│ • Prevents tampering in transit │
│ • Non-repudiation for disputes │
│ │
│ LAYER 5: REAL-TIME FRAUD DETECTION │
│ ────────────────────────────────── │
│ • Velocity checks (too many transactions too fast) │
│ • Amount anomaly detection │
│ • Geo-location checks (impossible travel) │
│ • Behavioral analysis │
│ • Block list matching │
│ │
└─────────────────────────────────────────────────────────────────────────┘
INFRASTRUCTURE SECURITY
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ NPCI DATA CENTERS │
│ ───────────────── │
│ │
│ • Tier-IV certified (99.995% uptime) │
│ • Chennai + Hyderabad (geographically separated) │
│ • FIPS 140-2 Level 3 certified HSMs │
│ • Active-Active configuration │
│ • N+N redundancy │
│ │
│ • Physical security: │
│ ├── Biometric access control │
│ ├── 24/7 security personnel │
│ ├── CCTV surveillance │
│ └── Man-trap entries │
│ │
│ BANK CONNECTIONS │
│ ──────────────── │
│ • Dedicated leased lines (not public internet) │
│ • Mutual TLS authentication │
│ • IP whitelisting │
│ • Regular security audits │
│ │
└─────────────────────────────────────────────────────────────────────────┘
# security/fraud_detector.py
"""
Real-Time Fraud Detection for UPI.
Must decide in < 50ms whether to allow a transaction.
"""
from dataclasses import dataclass
from typing import List, Tuple
from datetime import datetime, timedelta
@dataclass
class FraudSignals:
"""Signals used for fraud detection."""
user_id: str
device_id: str
amount: int
receiver_vpa: str
# Velocity
txn_count_1hr: int
txn_count_24hr: int
total_amount_24hr: int
# Device
is_new_device: bool
device_age_days: int
# Behavioral
is_new_receiver: bool
typical_amount: int
typical_time_of_day: List[int]
current_hour: int
# Location
device_location: str
usual_locations: List[str]
class FraudDetector:
"""
Real-time fraud detection.
Must be FAST (< 50ms) and ACCURATE (low false positives).
"""
def __init__(self, ml_model, rules_engine, blocklist):
self.model = ml_model
self.rules = rules_engine
self.blocklist = blocklist
async def evaluate(
self,
signals: FraudSignals
) -> Tuple[str, float, List[str]]:
"""
Evaluate fraud risk.
Returns: (decision, confidence, triggered_rules)
decision: "ALLOW", "BLOCK", "STEP_UP"
"""
triggered_rules = []
# RULE 1: Blocklist check (instant)
if await self.blocklist.is_blocked(signals.user_id):
return "BLOCK", 1.0, ["USER_BLOCKED"]
if await self.blocklist.is_blocked(signals.device_id):
return "BLOCK", 1.0, ["DEVICE_BLOCKED"]
# RULE 2: Velocity checks
if signals.txn_count_1hr > 10:
triggered_rules.append("HIGH_VELOCITY_1HR")
if signals.txn_count_24hr > 50:
triggered_rules.append("HIGH_VELOCITY_24HR")
if signals.total_amount_24hr > 100000_00: # ₹1 lakh in paise
triggered_rules.append("HIGH_AMOUNT_24HR")
# RULE 3: Amount anomaly
if signals.amount > signals.typical_amount * 10:
triggered_rules.append("AMOUNT_ANOMALY")
# RULE 4: New device
if signals.is_new_device:
triggered_rules.append("NEW_DEVICE")
if signals.amount > 10000_00: # > ₹10,000 on new device
triggered_rules.append("HIGH_AMOUNT_NEW_DEVICE")
# RULE 5: Unusual time
if signals.current_hour not in signals.typical_time_of_day:
triggered_rules.append("UNUSUAL_TIME")
# RULE 6: Location check
if signals.device_location not in signals.usual_locations:
triggered_rules.append("UNUSUAL_LOCATION")
# ML model for complex patterns
ml_score = await self.model.predict(signals)
# Decision logic
if ml_score > 0.9 or len(triggered_rules) > 3:
return "BLOCK", ml_score, triggered_rules
if ml_score > 0.7 or len(triggered_rules) > 1:
# Step-up: require additional verification
return "STEP_UP", ml_score, triggered_rules
return "ALLOW", 1 - ml_score, triggered_rules
Phase 5: Scaling and Edge Cases
Interviewer: "What happens during Diwali when everyone is sending money?"
You: "UPI handles 5x spikes during festivals. Here's how..."
Festival Traffic Management
DIWALI SCALE (5X NORMAL TRAFFIC)
Normal day:
├── ~640 million transactions
├── ~7,400 average TPS
├── ~25,000 peak TPS
Diwali:
├── ~3 billion transactions
├── ~35,000 average TPS
├── ~150,000+ peak TPS
└── Concentrated in evening hours (7 PM - 11 PM)
PREPARATION (Weeks Before):
├── Pre-scale infrastructure to 3x capacity
├── Warm up caches with popular VPAs
├── Notify banks to scale their systems
├── Extended support staff on standby
├── Runbooks reviewed and tested
DURING THE EVENT:
├── Auto-scaling triggers at 60% capacity
├── Non-critical features disabled (promotional notifications)
├── Enhanced monitoring (5-second alert intervals)
├── War room with all bank representatives
└── Direct escalation paths to bank CTOs
GRACEFUL DEGRADATION:
If overwhelmed:
├── Prioritize smaller transactions (more users served)
├── Rate limit per-user (max 5 txn/minute)
├── Queue non-urgent operations (mandate registrations)
└── Return "Try again in few minutes" vs hard failure
Critical Edge Cases
EDGE CASE 1: Bank System Down
Problem: SBI (largest bank, 30% market share) goes down
Impact: 30% of transactions fail
Solution:
├── Circuit breaker opens for SBI immediately
├── Return clear error: "SBI temporarily unavailable"
├── Pending transactions queued (if bank supports retry)
├── Status page updated
├── Auto-retry when circuit closes
└── Transactions involving SBI gracefully rejected
EDGE CASE 2: NPCI Switch Partial Failure
Problem: One NPCI data center fails
Impact: 50% capacity lost
Solution:
├── Active-Active setup in Chennai and Hyderabad
├── Traffic automatically routes to healthy DC
├── DNS TTL is low (60 seconds) for fast failover
├── Data replicated synchronously between DCs
└── RPO: 0 (no data loss), RTO: < 30 seconds
EDGE CASE 3: Duplicate Transaction Request
Problem: User's app times out, they retry, but first request succeeded
Impact: Double debit
Solution:
├── Every transaction has idempotency key
├── Generated on client: device_id + timestamp + amount + receiver
├── NPCI checks idempotency before processing
├── If duplicate: return original result
└── No double processing possible
EDGE CASE 4: April 2025 Outage (Real Incident)
What happened:
├── Banks were calling "Check Transaction Status" API excessively
├── Some banks called for old transactions repeatedly
├── NPCI didn't enforce rate limits on this API
├── API flooded, entire system degraded
Lesson learned:
├── Rate limit ALL APIs, not just transaction APIs
├── Enforce guidelines at NPCI firewall, not just bank side
├── Separate critical path APIs from status check APIs
└── Circuit breaker for misbehaving banks
Phase 6: Monitoring and Operations
You: "For a system processing ₹20 trillion monthly, monitoring isn't optional."
Key Metrics Dashboard
UPI OPERATIONS DASHBOARD
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ REAL-TIME HEALTH │
│ ───────────────── │
│ │
│ Transaction Rate Success Rate Latency (p99) │
│ ████████████████░ ██████████░ ████████░░ │
│ 7,842 TPS 99.2% 847 ms │
│ (Target: 10K) (Target: 99.0%) (Target: 1000ms) │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ BANK HEALTH MATRIX │
│ ────────────────── │
│ │
│ Bank TPS Success Latency Circuit Issues │
│ ───────────────────────────────────────────────────────────── │
│ SBI 2,341 98.7% 423ms CLOSED Minor lag │
│ HDFC 1,856 99.8% 287ms CLOSED Healthy │
│ ICICI 1,234 99.5% 312ms CLOSED Healthy │
│ Axis 987 94.2% 892ms HALF-OPEN HIGH LATENCY │
│ Kotak 654 99.1% 345ms CLOSED Healthy │
│ Yes Bank 543 99.4% 298ms CLOSED Healthy │
│ ... │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ ALERTS (Last 1 hour) │
│ ──────────────────── │
│ │
│ 🔴 14:32 - Axis Bank latency > 800ms (CRITICAL) │
│ 🟡 14:28 - SBI error rate 1.3% (Warning) │
│ 🟢 14:15 - Axis Bank circuit half-open (Info) │
│ 🟢 13:45 - Traffic spike +20% (Auto-scaled) │
│ │
└─────────────────────────────────────────────────────────────────────────┘
SLOs for UPI
UPI SERVICE LEVEL OBJECTIVES
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ SLO 1: TRANSACTION SUCCESS RATE │
│ ──────────────────────────────── │
│ Target: 99.0% of transactions succeed │
│ Measurement: Successful / Total (excluding user errors) │
│ Current: 99.2% │
│ │
│ Exclusions: │
│ • Insufficient balance (user error) │
│ • Wrong PIN (user error) │
│ • Account blocked (compliance) │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ SLO 2: END-TO-END LATENCY │
│ ────────────────────────── │
│ Target: 99% of transactions complete in < 2 seconds │
│ Measurement: Time from request received to response sent │
│ Current: p99 = 1.2 seconds │
│ │
│ Breakdown: │
│ • NPCI processing: < 300ms │
│ • Bank response (each): < 800ms │
│ • Network overhead: < 200ms │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ SLO 3: AVAILABILITY │
│ ──────────────────── │
│ Target: 99.9% uptime │
│ Measurement: (Total time - Downtime) / Total time │
│ Allowed downtime: 8.7 hours/year │
│ │
│ ───────────────────────────────────────────────────────────────────── │
│ │
│ SLO 4: MONEY SAFETY │
│ ───────────────────── │
│ Target: 100% of debited amounts credited or reversed │
│ Measurement: No money stuck > 5 business days │
│ Current: 99.99% resolved within 24 hours │
│ │
│ This is NON-NEGOTIABLE. Error budget = 0 │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Interview Conclusion
Interviewer: "Impressive depth. A few rapid-fire questions:"
Interviewer: "Why didn't India just adopt an existing system like Visa/Mastercard?"
You: "Three reasons:
- Cost: Card networks charge 1.5-3% per transaction. UPI is nearly free.
- Inclusion: Cards need credit checks, plastic production, POS terminals. UPI needs only a phone.
- Control: Critical financial infrastructure shouldn't depend on foreign companies.
The result: UPI enabled the chai vendor to accept digital payments for a ₹10 tea."
Interviewer: "What's the biggest technical achievement of UPI?"
You: "Interoperability without centralized money holding. NPCI routes transactions but never touches the money. This means:
- No counterparty risk (NPCI can't go bankrupt with your money)
- Banks remain the regulated entities
- Scales infinitely (NPCI is just a switch)
- Any app works with any bank
This architecture is why countries worldwide are studying UPI."
Interviewer: "If you were to improve UPI today, what would you change?"
You: "Based on the April 2025 outage:
- Stricter rate limiting at NPCI level, not trusting banks to self-regulate
- Better isolation between critical transaction APIs and status check APIs
- More granular circuit breakers — per-API, not just per-bank
- Chaos engineering — regularly test failure scenarios in production"
Summary: Concepts Applied from 10-Week Course
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ CONCEPTS FROM 10-WEEK COURSE IN UPI DESIGN │
│ │
│ WEEK 1: DATA AT SCALE │
│ ├── Partitioning: VPAs partitioned by bank suffix │
│ ├── Replication: Multi-DC active-active setup │
│ └── Read optimization: VPA caching at NPCI level │
│ │
│ WEEK 2: FAILURE-FIRST DESIGN │
│ ├── Timeouts: Strict timeouts for bank calls (30s) │
│ ├── Circuit breakers: Per-bank failure isolation │
│ ├── Idempotency: Transaction idempotency keys │
│ └── Retries: Smart retry with exponential backoff │
│ │
│ WEEK 3: MESSAGING & ASYNC │
│ ├── Transactional outbox: Audit logging │
│ ├── Dead letter queues: Failed reversal handling │
│ └── Event streaming: Transaction events for reconciliation │
│ │
│ WEEK 4: CACHING │
│ ├── VPA resolution caching │
│ ├── Bank configuration caching │
│ └── Negative caching: Non-existent VPAs │
│ │
│ WEEK 5: CONSISTENCY & COORDINATION │
│ ├── Distributed transactions: Debit-then-credit with rollback │
│ ├── State machine: Transaction lifecycle management │
│ └── Exactly-once semantics: Idempotency guarantees │
│ │
│ WEEK 9: SECURITY & COMPLIANCE │
│ ├── Multi-factor authentication: Device + PIN │
│ ├── Encryption: PBKDF2, HSM-based PIN verification │
│ ├── Fraud detection: Real-time ML scoring │
│ └── Audit trail: Complete transaction logging │
│ │
│ WEEK 10: PRODUCTION READINESS │
│ ├── SLOs: Success rate, latency, availability targets │
│ ├── Observability: Per-bank health dashboards │
│ ├── Capacity planning: Festival traffic handling │
│ └── Incident management: April 2025 outage learnings │
│ │
└─────────────────────────────────────────────────────────────────────────┘
Why UPI Matters
╔═════════════════════════════════════════════════════════════════════════╗
║ ║
║ WHY UPI IS A MARVEL OF ENGINEERING ║
║ ║
║ SCALE ║
║ ───── ║
║ • 50% of world's digital transactions ║
║ • More than Visa + Mastercard combined (in India) ║
║ • 640+ million transactions DAILY ║
║ ║
║ INCLUSION ║
║ ───────── ║
║ • Works on ₹3,000 smartphones ║
║ • Works on 2G networks ║
║ • ₹1 transactions viable (no minimums) ║
║ • Enabled 300 million+ previously unbanked Indians ║
║ ║
║ COST ║
║ ──── ║
║ • Zero cost to consumers ║
║ • Near-zero cost to small merchants ║
║ • Saved billions in card network fees ║
║ ║
║ INNOVATION ║
║ ────────── ║
║ • VPA system (email for money) ║
║ • Interoperable (any app, any bank) ║
║ • Open standard (countries can adopt) ║
║ • Built on existing bank infrastructure ║
║ ║
║ GLOBAL IMPACT ║
║ ───────────── ║
║ • 8+ countries accepting UPI ║
║ • 10+ countries studying UPI for adoption ║
║ • Model for BIS cross-border payment initiatives ║
║ ║
║ ════════════════════════════════════════════════════════════════════ ║
║ ║
║ "UPI proved that with the right architecture, a developing nation ║
║ can leapfrog decades of financial infrastructure and build ║
║ something the developed world envies." ║
║ ║
╚═════════════════════════════════════════════════════════════════════════╝
Self-Assessment Checklist
After studying this case study, you should be able to:
Architecture:
- Explain the three-layer UPI architecture (Apps → NPCI → Banks)
- Design a VPA resolution system with caching
- Implement atomic transactions with rollback capability
Distributed Systems:
- Handle partial failures in multi-party transactions
- Implement circuit breakers for unreliable dependencies
- Design idempotency for payment systems
Scale:
- Calculate infrastructure needs for billion-transaction systems
- Plan for bursty traffic (festivals, events)
- Implement graceful degradation under load
Security:
- Design multi-factor authentication for payments
- Implement real-time fraud detection
- Understand HSM-based PIN verification
Operations:
- Define meaningful SLOs for payment systems
- Monitor multi-party systems (NPCI + 680 banks)
- Learn from production incidents (April 2025 outage)
Sources
Statistics and Data:
- NPCI Official UPI Statistics: https://www.npci.org.in/product/upi/product-statistics
- Business Standard - UPI December 2024 Data: https://www.business-standard.com/finance/news/upi-transactions-surge-to-record-16-73-bn-in-dec-value-at-rs-23-25-trn-125010100457_1.html
- DemandSage UPI Statistics 2025: https://www.demandsage.com/upi-statistics/
- Meetanshi UPI Statistics: https://meetanshi.com/blog/upi-statistics/
- GrabOn UPI Statistics: https://www.grabon.in/indulge/tech/upi-statistics/
Architecture and Technical Details:
- Wikipedia - Unified Payments Interface: https://en.wikipedia.org/wiki/Unified_Payments_Interface
- ByteByteGo - UPI Architecture: https://bytebytego.com/guides/unified-payments-interface-upi-in-india/
- GeeksforGeeks - Designing UPI System Design: https://www.geeksforgeeks.org/designing-upi-system-design/
- Medium - Deep Dive System Design of UPI: https://medium.com/@avinashkariya05910/deep-dive-system-design-of-upi-unified-payments-interface-eff3b0334b0d
- Brickendon Consulting - UPI Technical Overview: https://www.brickendon.com/insights/unified-payments-interface-upi/
- Dev.to - System Design UPI: https://dev.to/zeeshanali0704/system-design-upi-unified-payment-interface-2ng3
Infrastructure and Security:
- ITNews Asia - NPCI Data Center Modernization: https://www.itnews.asia/news/indias-npci-modernises-data-centres-using-kyndryls-cloud-services-592061
- NPCI Smart Data Center Press Release: https://www.npci.org.in/PDF/npci/press-releases/2020/NPCI_Press_Release-NPCI_to_launch_Smart_Data_Center_in_Hyderabad.pdf
- The420.in - UPI Security Infrastructure: https://the420.in/upi-digital-payments-infrastructure-security-npci-cpt-analysis/
- Blog - UPI Security Architecture Deep Dive: https://blog.akshanshjaiswal.com/the-upi-architecture-a-security-look
Settlement and Operations:
- BillCut - Settlement Latency Benchmarks: https://www.billcut.com/blogs/settlement-latency-benchmarks-whos-fastest/
- Razorpay - UPI Payout Processing: https://razorpay.com/blog/business-banking/payout-processing-imps-upi-transactions-deemed-success-npci/
- Inc42 - NPCI Real-Time Fix for UPI Failures: https://inc42.com/buzz/ncpi-working-on-real-time-fix-for-upi-transaction-failures/
- BIS Papers - Faster Digital Payments India: https://www.bis.org/publ/bppdf/bispap152_e_rh.pdf
Outage Analysis (April 2025):
- Wikipedia - UPI Outage Details: https://en.wikipedia.org/wiki/Unified_Payments_Interface
Further Reading
Official Documentation:
- NPCI Official Website: https://www.npci.org.in/
- NPCI UPI Product Page: https://www.npci.org.in/what-we-do/upi/product-overview
- RBI Payment Systems: https://www.rbi.org.in/Scripts/PaymentSystems_UM.aspx
- UPI Procedural Guidelines: https://yashada.org/yashada_2019/pdfs/e_library_cit/edpri_UPI_Procedural_Guidelines.pdf
Engineering Blogs and Technical Deep Dives:
- Razorpay Engineering Blog: https://razorpay.com/blog/ (Multiple articles on UPI integration)
- Paytm Engineering: https://paytm.com/blog/ (UPI transaction insights)
- ByteByteGo Newsletter: https://blog.bytebytego.com/ (System design breakdowns)
- LinkedIn Engineering Posts: Search "UPI Architecture" for practitioner insights
Research Papers and Reports:
- BIS Papers No. 152: Faster Digital Payments - Global and Regional Perspectives (India Chapter)
- NPCI White Papers: Available on NPCI website
- RBI Annual Reports: Digital payments statistics and trends
News and Industry Analysis:
- Medianama: https://www.medianama.com/ (Digital payments coverage)
- Economic Times Tech: https://economictimes.indiatimes.com/tech (Fintech news)
- Inc42: https://inc42.com/ (Startup and fintech coverage)
- LiveMint: https://www.livemint.com/ (Financial news)
Video Resources:
- NPCI YouTube Channel: Official explainers and announcements
- System Design Interview Videos: Search "UPI System Design" on YouTube
Books:
- "Designing Data-Intensive Applications" by Martin Kleppmann - Foundational concepts
- "System Design Interview" by Alex Xu - Interview preparation with similar patterns
Related Systems to Study:
- PIX (Brazil): Similar instant payment system
- FedNow (USA): US real-time payment system
- SEPA Instant (Europe): European instant payments
End of Bonus Problem 1: India's UPI
"A payment system that serves a billion people, handles trillions in transactions, and costs nothing to use. This is what engineering at scale looks like."