went through interview loops at 4 fintech companies. system design at these places is nothing like "design twitter" — they don't care how you scale to 1B users. they care whether YOU understand what breaks when money is involved.

heres the pattern nobody explains:

they always test the same 5 constraints:

1. idempotency — if a payment request retries (network timeout, user double-taps), the money can't move twice. you need a client-generated idempotency key checked BEFORE any downstream call. mention this in your first 2 minutes or you've already lost.

2. strong consistency for the ledger, eventual for the UI — the record that says "money moved" MUST be strongly consistent. but the user's transaction history in the app? that can lag by 100ms. these are two different consistency decisions in the SAME system.

3. downstream rate limits — the bank/NPCI/gateway is your bottleneck, NOT your service. autoscaling your API doesn't help if your queue backs up at a system you don't control. split sync validation from async processing via a queue.

4. retry storms — client timeouts spike during peak load → retries compound → 10x traffic becomes 30x. idempotency + backoff + circuit breakers are the trio that saves you.

5. reconciliation — no matter how careful, some transactions will end up in weird states (ledger says SUCCESS, bank shows nothing). you need async reconciliation jobs that compare your records with the counterparty's daily settlement file. designs without this get rejected.

questions actually asked (2025 loops):

• "10x UPI transaction spike during flash sale. bank PSP can't be scaled. handle it." (PhonePe)
• "payment success rate dropped 3% after deploy, no alerts firing. root cause it." (PhonePe)
• "user's payment times out but succeeded on backend. they retry. how do you prevent double debit?" (Razorpay pattern)
• "design the ledger service. product wants instant UI updates. infra wants consistency. resolve." (PhonePe)
• "your service does 5000 TPS. bank rate-limits at 1000 TPS. now what?" (Stripe-style)

the answer framework i now use:

1. FIRST 30 seconds: name what can't go wrong ("money can't be lost or duplicated. this dictates every design choice below.")
2. draw the request path SPLIT into sync (validate + idempotency check + ACK) and async (queue → downstream processing)
3. add reconciliation as a first-class component, not an afterthought
4. discuss failure modes for EACH arrow in your diagram — this is where most candidates lose points

interviewers at fintech love when you proactively mention idempotency and reconciliation. its the signal that separates "generic system design candidate" from "someone who has actually thought about money."

the resource i used for fintech-specific designs (idempotency deep dive, ledger consistency, saga pattern for distributed transactions): systemcraft.in/hld/DigitalWallet covers the payment orchestration + reconciliation flow, and systemcraft.in/hld/BookMyShow covers idempotency keys in the payment saga.

if you're prepping for phonepe, razorpay, stripe, cred, paytm, or any fintech — dont treat it like generic system design. the constraints are different and the interviewers will penalize you for not knowing that.

whats the trickiest fintech interview question you've had? for me it was "how do you reconcile a payment where your ledger says failed but the bank shows successful" — took me a while to realize the answer is "we don't autofix, we alert ops for manual review because auto-correcting money movements is illegal."