UPI-scale throughput, transaction state across banks, and designs that must degrade gracefully rather than fail.
PhonePe operates at UPI volumes, so its design rounds start where most candidates stop. Throughput assumptions that are fine in a generic answer - a single relational primary, synchronous calls between services - fall over immediately, and interviewers will say so. Sharding strategy, write path design and back-pressure are expected rather than bonus material.
The second distinctive area is dependency on systems you do not control. A UPI transaction crosses banks with varying latency and reliability, so designs must answer what happens when the remote side is slow, returns ambiguously, or answers after you have already timed out. Graceful degradation and a clear reconciliation story matter more than a clever happy path.
45-60 min
Medium to hard, with real complexity discussion.
60-90 min
Model transaction state and its transitions in working code.
60 min
High-throughput transaction processing, sharding, and cross-bank failure handling.
45 min
Ownership of high-scale, correctness-critical systems.
Assume the numbers break a single-node answer and say so explicitly. Work out the write rate, show why one primary cannot serve it, then choose a shard key and explain how you avoid hot partitions on popular merchants.
Treat the remote side as unreliable by definition. Define timeouts, describe the ambiguous-response case where you do not know whether the debit happened, keep the transaction in an explicit pending state, and reconcile rather than guess.
Medium to hard, and genuinely weighted. It is not a formality - but the design round is usually where the level is decided.
Practise the rounds PhonePe actually runs, and get scored on where you stand.