Razorpay Software Engineer Interview: Questions & Prep (2026)

Razorpay software engineer interviews look like a standard product-company loop on the surface — DSA rounds plus system design — but the design bar is payments-specific. The loop typically runs online assessment or recruiter screen → one or two DSA rounds → a system design round → a hiring manager round; junior candidates sometimes get a machine-coding round instead of full distributed design. What separates Razorpay's design round from a generic one is the domain physics of money movement: every API must be idempotent because clients retry, every ledger entry must balance because money can't be approximately correct, webhooks must survive flaky merchant servers, and payment flows must stay available through bank and gateway outages. Candidates report interviewers care less about buzzword architecture and more about whether you can reason about failure: what happens when the response is lost after the debit succeeded? If you're still building your overall candidacy, start with the broader guide on [how to get hired at Razorpay](/company_guide/how-to-get-hired-at-razorpay.html).

1. Design an idempotent payments API: a client retries a charge request after a timeout — how do you guarantee the customer is charged exactly once?
2. Design a double-entry ledger service. How do you keep balances consistent under concurrent transactions, and how do you detect drift?
3. Design a webhook delivery system that guarantees at-least-once delivery to merchant servers that are frequently down. Cover retries, ordering, and backoff.
4. A payment gateway is timing out on 30% of requests. Design routing that keeps payment success rates high during partial outages.
5. Given a stream of transactions, detect duplicates within a sliding time window (hashing + window data structures).
6. Implement a rate limiter per merchant API key — token bucket vs. sliding window log, and where the state lives in a distributed deployment.
7. Reconciliation: given two large files — your ledger entries and the bank's statement — find mismatched, missing, and duplicate transactions efficiently.
8. Design a distributed job scheduler for settlement runs that must execute exactly once per merchant per day.
9. LRU/LFU cache implementation, then: where would caching be dangerous in a payments flow?
10. Parse and validate transaction strings (UPI IDs, card BINs) — string manipulation with strict edge-case handling.
11. How would you store money amounts and why is floating point the wrong answer?
12. Tell me about a time you shipped something that failed in production — what did you do?

Q: Given a stream of transactions, detect duplicates within a 10-minute window.

Clarify first: what defines a duplicate — same transaction ID, or same (merchant, amount, card) tuple within the window? Assume the tuple. Maintain a hash map from tuple-hash → latest timestamp, plus a deque (or min-heap) of entries ordered by time for eviction; each incoming transaction evicts expired entries from the front, then checks the map in O(1) amortised. State complexity unprompted: O(1) amortised per transaction, O(W) space for W transactions in the window. Then raise the scale and correctness follow-ups yourself: at multi-datacentre scale, a local map misses cross-node duplicates, so you'd back it with a shared store like Redis using SET with NX and a TTL equal to the window — which is exactly an idempotency-key check. Mention the trade-off: a Bloom filter cuts memory but false positives would block legitimate payments, so in a payments context you accept the memory cost for exactness.

Q: Design an idempotent charge API with a consistent ledger behind it.

Outline: (1) Contract — every charge request carries a client-generated idempotency key; same key returns the same result, never a second charge. (2) Write path — insert the key into an idempotency table with a unique constraint in the same database transaction that creates the payment record; a duplicate insert means a retry, so return the stored response. Keys expire after a retention window. (3) Ledger — double-entry: every movement writes two balanced entries (debit customer-side, credit merchant-side) atomically; balances are derived, and the ledger is append-only — corrections are reversal entries, never updates. (4) The hard failure — the gateway charged the card but your response was lost: the payment sits in a PENDING state, and an async reconciliation worker polls gateway status to converge it to success or reversal. (5) Trade-off to state aloud: within a ledger shard you choose strong consistency over availability, because an unavailable ledger is recoverable but an incorrect one is not.

Q: Tell me about a time something you shipped failed in production.

*Situation:* At my previous company I shipped a notification service change that silently dropped webhook events for about 3% of callbacks during a dependency upgrade.

*Task:* I owned detection, customer impact, and the permanent fix.

*Action:* A merchant complaint surfaced it before our alerts did — the failure mode was silent. I wrote a replay script against our event log to redeliver every dropped webhook within 24 hours, added delivery-rate alerting with a per-endpoint success threshold, and moved the pipeline to an outbox pattern so events were persisted before acknowledgement.

*Result:* All affected events were redelivered with zero data loss, delivery observability caught two unrelated regressions in the following quarter, and the outbox pattern became the team standard. The takeaway I'd bring to Razorpay: in money-adjacent systems, silent failure is the worst failure — instrument delivery, not just errors.

For DSA rounds: clarify constraints, state the brute force and its complexity, improve, then dry-run an edge case — interviewers typically grade the reasoning path, not just the final code. For payments system design, run requirements → API contract → data model → happy path → failure path, and spend the most time on failure: lost responses, double sends, partial writes. Three domain patterns cover most Razorpay design questions — idempotency keys with unique constraints for exactly-once effects, double-entry append-only ledgers for money correctness, and the outbox pattern plus retries with exponential backoff for reliable webhook delivery. Always name your consistency choice per component: ledgers get strong consistency; notification and analytics paths can be eventual. For behavioural rounds, use STAR with a quantified result, and pick stories showing ownership through failure.

Candidates report the strongest signal is failure-mode reasoning: when you describe a design, do you volunteer what happens when the network partitions mid-charge, or does the interviewer have to drag it out of you? Second is correctness instinct — knowing why money is stored in integer minor units not floats, why ledgers are append-only, and why a cache in the debit path is dangerous. Third, standard DSA competence with clean, tested code; Razorpay's bar is typically LeetCode medium with an emphasis on edge-case discipline, which mirrors production payments work. In hiring manager rounds, ownership stories carry weight — candidates report incidents owned end to end land better than greenfield features, because payments engineering is substantially about operating systems safely.

Weeks 1–2: DSA with a bias toward hashing, heaps, sliding windows, and string parsing — 35–40 timed problems, always stating complexity aloud and testing edge cases before declaring done. Week 3: payments design patterns — implement a toy idempotency-key store and a double-entry ledger in a weekend project; you'll internalise the unique-constraint and append-only patterns far faster by building them. Then rehearse four designs end to end: idempotent charge API, webhook delivery, gateway routing under partial outage, and reconciliation. Week 4: mocks and stories — one DSA mock, one design mock, plus four STAR stories (an incident, a technical decision, a conflict, a failure) each with a number in the result. While you prep, keep your pipeline warm: [knok](https://knok.work/) searches 150+ job boards overnight, surfaces only high-fit engineering roles, and drafts hiring-manager outreach, so practice hours don't come at the cost of applications.

Designing the happy path and waiting to be asked about failures — in a payments loop, failure handling is the question. Suggesting floats for money, mutable ledger rows, or caching in the debit path; each is a fast negative signal. Saying "exactly-once delivery" for webhooks instead of at-least-once delivery with idempotent consumers — candidates report interviewers probe this distinction deliberately. Hand-waving retries without idempotency, which doubles charges. In DSA rounds, skipping edge cases (empty input, duplicates, overflow) that payments interviewers specifically watch for. And claiming knowledge of Razorpay's internal architecture — hedge with "I'd validate this against your stack."