Does Razorpay SDE-2 have a system design round?

Yes, Razorpay SDE-2 includes a system design round.

Razorpay

Q: How many rounds are there in Razorpay SDE-2 interviews?

Razorpay SDE-2 typically has 5 rounds. Razorpay SDE-2 interviews add a full system design round where fintech correctness — idempotency, exactly-once delivery, reconciliation — is expected knowledge, not a bonus. The machine coding bar rises to production-quality design with pluggable components and comprehensive tests. SQL questions involve multi-table joins on payment-scale data and deep ACID discussion. Five rounds; the machine coding round is still where most candidates with 3–5 years of experience get cut.

Q: What topics are tested in Razorpay SDE-2 interviews?

Razorpay SDE-2 interviews test: Strategy Pattern, Repository Pattern, Idempotency, Retry Logic, Testing, Sliding Window, Heaps, Interval Scheduling.

Fintech · Bengaluru, India

Razorpay is India's leading payments infrastructure company, powering payment acceptance for 8M+ businesses.

Related Companies

Rounds: 5 rounds
Focus: Machine Coding + DSA + SQL + System Design
System Design: Yes
Timeline: 3–4 weeks to offer

Role:

Rounds 1–2 are fully visible · Round 3+ unlocked with a free account

Machine Coding

Round 1 of 5LLD / OOD

90 min

Strategy PatternRepository PatternIdempotencyRetry LogicTesting

Production-quality LLD with multiple layers. At SDE-2, the bar is a design another engineer could maintain and extend — not just a working implementation. Recent problems include pub-sub queues with delivery guarantees, notification routing systems with configurable destinations, and payment orchestrators with multi-provider fallback. The most common rejection at this level: a monolithic class that works but can't accommodate the bonus requirement the interviewer adds at the 60-minute mark.

Medium

What to expect

e.g., 'Build a pub-sub queue with offset management and at-least-once delivery' — consumer groups, offset tracking, retry on unacknowledged messages
e.g., 'Implement a configurable Logger framework' — multiple sinks (file, stdout, remote), log levels, sink routing by configuration, extensible without touching existing sinks
e.g., 'Build a Payment Gateway Orchestrator' — multiple providers (Stripe, PayU), success-rate-based routing, automatic fallback chain on timeout or failure
Pluggable provider pattern: 'Adding a new payment provider should require zero changes to existing routing code' — interviewer checks extensibility explicitly
Idempotency probe: 'How do you ensure that if the network drops after charging but before acknowledgment, the merchant is not charged twice?'
Full test suite expected — happy path, network timeout, partial failure, concurrent requests

Practice on KnowEase.AI

LLD Practice →

Coding Round

Round 2 of 5DSA / Coding

60 min

Sliding WindowHeapsInterval SchedulingThread Safety

Medium-Hard DSA with fintech framing and a concurrency follow-up. Razorpay interviewers at SDE-2 consistently ask 'is this function thread-safe?' after the initial solution — even in a pure coding round. The expectation is that you understand concurrency risks in a payments context, not just that you can fix them if asked.

Medium

What to expect

e.g., 'Given a stream of payment events, compute the top 5 merchants by transaction volume in the last 1 hour' — sliding window + min-heap of size 5
e.g., 'Find the maximum set of non-overlapping settlement windows for a reconciliation batch' — interval scheduling (greedy, sort by end time)
e.g., 'Given a transaction dependency graph, detect all merchants in a payment cycle' — DFS with visited/in-progress coloring
Concurrency probe: 'Two threads call this function simultaneously with the same merchant ID — what breaks and how do you fix it?'
Scale check: 'Razorpay processes 50M transactions per day. At what input size does your O(n log n) approach become a problem?'

Practice on KnowEase.AI

DSA Practice — Sliding Window →DSA Practice — Heaps →

Technical + SQL Round

Round 3 of 5SQL Round

60 min

Rolling Window SQLIndex OptimizationDijkstraACID Isolation Levels

Hard DSA plus complex SQL on payment-scale tables. At SDE-2, SQL questions involve rolling window fraud detection, multi-join settlement analysis, and query optimization on 500M+ row tables. The indexing question is graded on reasoning, not just the right answer — you need cardinality estimates and access pattern justification. The ACID deep dive here is harder than at SDE-1: expect distributed transaction scenarios, not just isolation level definitions.

What to expect

SQL: 'Find merchants where the fraud rate (failed_amount / total_amount) exceeded 5% in any 30-day rolling window' — window functions with RANGE BETWEEN INTERVAL '30' DAY PRECEDING AND CURRENT ROW
SQL: 'For each payment method, show average settlement time by bank, broken down by weekday vs weekend' — GROUP BY with CASE WHEN, multi-level aggregation
Indexing: 'Your fraud query runs on a payments table with 500M rows. Explain which composite index you'd create and why, with cardinality reasoning'
DSA: 'Find the shortest settlement path between two correspondent banks in a routing graph' — Dijkstra with weighted edges representing transaction fees
ACID deep dive: 'A payment debit and credit must both succeed or both fail. Why is two-phase commit insufficient in a distributed microservices context? What's your alternative?'

Full details unlocked with a free account

System Design

Round 4 of 5System Design

60 min

IdempotencyWebhook DeliveryDistributed TransactionsSaga PatternFraud Hooks

Design a core payments infrastructure component. The most important thing to know: at Razorpay, idempotency is expected knowledge, not a bonus insight. If you don't mention idempotency keys in the first 10 minutes of designing a payment API, the interviewer notices. A beautifully scaled system that can double-charge on a network retry fails this round regardless of throughput numbers.

What to expect

e.g., 'Design Razorpay's Payment Gateway' — merchant API layer, multi-PSP routing with ML-based success rate selection, async settlement, webhook delivery
Idempotency: 'How do you prevent a merchant from being charged twice when their client retries a timed-out request? Walk me through the exact DB schema and flow'
Webhook reliability: 'How do you guarantee at-least-once delivery of payment status webhooks across 200K merchants with retry + exponential backoff + dead-letter queue?'
Partial failure: 'The charge to the customer's bank succeeds but the settlement to the merchant's account fails — what does your system do? How does a human operator find and fix this?'
Unknown outcome: 'Your call to HDFC's API times out — you don't know if the charge happened. How do you handle this without charging the customer twice or leaving them without service?'

Full details unlocked with a free account

Hiring Manager

Round 5 of 5Behavioral / HM

45 min

Incident OwnershipReliability MindsetFintech Domain

Technical depth plus reliability mindset check. The HM at SDE-2 picks one past incident and one past system and drills into both — what you'd redesign, what you got wrong, and how you think about reliability in a system where downtime or bugs have direct financial consequences for merchants.

What to expect

Incident deep dive: 'Walk me through a production incident in a high-stakes system. How did you ensure no money was lost or double-charged during the recovery?'
Reliability trade-off: 'How do you maintain a service that cannot go offline for maintenance? What's your zero-downtime migration strategy?'
Domain fit: 'How do you think about the trade-off between payment latency and fraud detection accuracy? What do you sacrifice first and why?'
India payments ecosystem: 'Explain how a UPI payment flows end-to-end — NPCI, PSP, bank, VPA resolution. Where does Razorpay fit and where does complexity live?'

Full details unlocked with a free account

Questions — coming soon.

Company Guide — coming soon.

About Razorpay SDE-2 Interviews

Razorpay SDE-2 interviews add a full system design round where fintech correctness — idempotency, exactly-once delivery, reconciliation — is expected knowledge, not a bonus. The machine coding bar rises to production-quality design with pluggable components and comprehensive tests. SQL questions involve multi-table joins on payment-scale data and deep ACID discussion. Five rounds; the machine coding round is still where most candidates with 3–5 years of experience get cut.

See interview loops for other companies:

Microsoft Amazon Uber Flipkart Walmart Coupang Rippling Rubrik Target

Start your Razorpay SDE-2 prep plan

Practice the exact topics tested in each round — DSA, system design, SQL, and LLD.

Start free →