What to Expect in the Razorpay System Design Interview

Razorpay splits design into two rounds, and the machine coding round matters most. Candidates report a live machine coding session where you build a small working system in roughly one to two hours, while senior candidates report a separate high level design round of about an hour.

The machine coding round grades running code, while the design round grades the quality of the discussion. Reported machine coding problems include an in-memory relational database, an in-memory search engine, a notification service, and a logger with several output destinations.

The Machine Coding Round

A machine coding round is a live session where you build a small program, usually a console application, from an open question. The grade depends on three things: whether the program runs, how the classes are organized, and whether a new requirement can be added without a rewrite. That makes it different from a design discussion, as the difference between system design and low level design explains in detail.

Candidates report these Razorpay problems:

• An in-memory relational database. Create tables, then insert, update, delete, and search rows, with primary keys, indexes, and column constraints.
• An in-memory search engine. Add and remove documents, then return every document that contains the words in the search query.
• A notification system. Send messages through several channels, with message types and rules that decide the routing.
• A logger. Accept log levels such as warning and error, then write each level to its configured destination.

Candidates report that interviewers add a bonus requirement partway through the session, which tests how easily the design extends, and one candidate reports a rejection despite a correct and optimal solution because the code was judged insufficiently modular. Write interfaces for the parts that will change, keep the names meaningful, and finish with a program that compiles and runs. For the general shape of this round, see what a machine coding round involves.

The High Level Design Round

Senior candidates report a design round of about an hour, usually held over video, and one reported question asks for a notification service that delivers email, SMS, and push messages at large volume. The other likely topics come from Razorpay's own product, so prepare payment problems as well.

Payment flows and idempotency. Idempotency means that a repeated request returns the first result instead of acting a second time, and Razorpay documents idempotency keys in its public API, so a design that charges a customer twice on a retry fails this round.

Reconciliation. Banks and card networks confirm many transactions hours after the payment request, so be ready to explain how your system settles the difference between what you recorded and what the bank later reports.

Rate limiting and routing. A payment gateway receives sudden traffic spikes during large sale events, and Razorpay has written publicly about rate limiting at the proxy layer. Expect questions about limits per merchant, and about routing a payment to a second provider when the first one fails.

A Walkthrough: Design a Notification Service

Here is a high level plan for the reported question.

1. Requirements (5 minutes). Settle the channels, which are email, SMS, push, and webhooks, and settle the volume, which the question sets at millions of messages each day, then confirm two rules: no duplicate delivery, and transactional messages ahead of promotional ones.

2. Ingestion. Services publish notification events to a queue, and that queue absorbs traffic spikes so the calling service returns quickly.

3. Preference and template service. Check whether the user accepts this channel for this message type, then render the text from a stored template.

4. Channel workers. Run one worker pool per channel, where each worker calls an external provider, such as an SMS vendor, and a second provider stays ready for failover.

5. Delivery guarantees. Give every notification a unique key and store that key before sending, so a retry after a timeout does not deliver the same message twice.

6. Retries and dead letters. Retry failed sends with growing delays, and after a fixed number of attempts move the message to a dead letter queue for inspection.

7. Scale and monitoring. Separate the queue for transactional messages from the queue for promotional ones, then track delivery rate, provider latency, and failure rate for each provider.

What the Interviewer Grades

Practical judgment counts more than unusual components, so state the requirements before you draw any boxes and name the trade-off in each choice out loud. Connect every decision to the merchant, because a failed payment is lost revenue for a real business, and candidates report interviewers who ask repeated follow-up questions on depth, so defend each choice with a reason.

Common Mistakes in This Round

• Pseudo-code in the machine coding round. Razorpay reports say the code must compile and run, so an elegant sketch that does neither scores badly.
• One class that does everything. Extensibility is the graded property here, so split the responsibilities before you write any logic.
• Skipping idempotency. In a payment system, this is the first thing that a strong interviewer will check.
• No failure story. Providers time out and banks confirm late, so a design without retries and reconciliation is unfinished.
• Silent working. Both rounds grade your reasoning as much as your result, so say what you are choosing and why.

How to Prepare

• Build five machine coding problems without a reference solution. Parking lot, expense sharing, logger, in-memory database, and notification service, each in ninety minutes.
• Learn the class structure. Grokking the Object Oriented Design Interview teaches the modeling this round grades.
• Learn the building blocks. Grokking the System Design Interview covers queues, caches, and replication.
• See the whole loop. The design rounds belong to the Razorpay interview process, next to the motivation question and the reported waits after each round.