Fintech System Design Interviews India 2026: Zerodha, Groww, PhonePe, Paytm

In a social or content system, an eventual-consistency bug shows a slightly stale like count. In a fintech system, the equivalent bug shows a wrong account balance, a double-charged customer, or a position that disagrees with the exchange. That difference reshapes the whole interview.

Expect interviewers to keep asking three questions in different forms:

• Is the hot path fast enough? (order acknowledgement, payment authorisation)
• Is money movement correct under retries and duplicates? (idempotency)
• What happens on a mismatch? (reconciliation, audit trails, alerting)

Candidates who lead with a microservices diagram but never mention idempotency or reconciliation tend to fail these rounds even when the diagram is clean.

Zerodha runs one of India's largest retail brokerages on a deliberately lean stack, so its rounds prize latency and correctness over web-scale CRUD. Common prompts:

• Acknowledge a Kite order in single-digit milliseconds during the 9:15 AM market-open surge. Where are your bottlenecks?
• Stream live market ticks to millions of concurrent users without melting the backend (fan-out, connection management).
• End-of-day reconciliation between trades, the exchange, and the depository so no position is ever wrong.

Strong answers identify the hot path and its latency budget first, then design money-movement correctness with idempotency and audit trails, and state clearly what happens on a mismatch. Treating a reconciliation bug as a regulatory event is exactly the instinct interviewers want to see.

Groww spans mutual funds, stocks, and F&O for a huge retail base, so its system-design rounds probe correctness of money movement and eventual consistency of portfolio views. Common prompts:

• Design the mutual-fund order and portfolio system so holdings and NAV update correctly across SIPs, redemptions, and market close. What is your source of truth?
• Design the SIP scheduler that executes millions of recurring investments on the same date each month without double-charging or missing any.
• Design a watchlist and price-alert service that evaluates millions of alert rules cheaply and pushes the moment a stock crosses a target.

The recurring theme is a clear source of truth, idempotent execution of scheduled money movement, and reconciliation with RTAs and exchanges.

PhonePe and Paytm frame problems around UPI and wallet scale. While both run classic coding rounds, their design and applied-DSA questions stay in-domain:

• Top-K merchants by volume over a UPI transaction stream in a sliding window.
• A rate limiter that allows thousands of requests per second per merchant, and how it behaves at the boundary.
• Detecting duplicate transaction IDs over an unbounded stream, and merging K sorted settlement logs into one time-ordered ledger.

The expected framing is always the same: correct solution, honest complexity analysis, then a sentence on idempotency, concurrency, or memory because the code sits in a real payments backend.

Use this order for any fintech design question:

1. Clarify the money-movement contract: what must never happen (double-charge, lost payment, wrong balance)?
2. Estimate the hot path: requests per second at peak, and the latency budget for the critical action.
3. Design the write path with idempotency keys so retries and duplicate callbacks are safe.
4. Design the read path for the views users see (portfolio, balance), accepting eventual consistency where it is safe.
5. Add reconciliation and audit: how you detect and resolve a mismatch, and what you alert on.

Lead with the contract and the failure handling, not the diagram. That is the difference between a generic answer and one that reads as fintech-native.