Razorpay System Design Interview: What the Bar Actually Tests

Most candidates preparing for the Razorpay system design interview expect one design round. They get two. The one they didn't prepare for is the one that ends the process.

This is not a FAANG loop where design rounds blur together or occasionally get skipped. Razorpay runs a Low-Level Design round and a High-Level Design round as separate, independent gates. Miss either and the process ends there. It does not matter how cleanly you solved the graph problem. Fail the LLD, and that is that.

The Full Interview Loop

Most backend SDE candidates encounter something like this:

Round	Format	Duration	Focus
Online Assessment	Remote	90 min	DSA, OS/DBMS/OOP MCQs
DSA / Coding	Live	60-90 min	LeetCode medium, graphs, strings
Machine Coding (LLD)	Live coding	90 min	Object design, extensibility
System Design (HLD)	Verbal/whiteboard	60 min	Scalability, trade-offs
Hiring Manager	Conversation	45-60 min	Projects, behavioral, career

Not every candidate hits all five. SDE1 candidates sometimes skip HLD entirely. Senior and Staff candidates often get an extra depth conversation on top of the standard HLD. The machine coding round, though, is nearly universal for experienced hires.

The LLD Round Is Razorpay's Real Filter

The machine coding round is where most experienced candidates get cut, because they prepared for the HLD and assumed LLD was the easier warmup.

Here is what actually happens. You get a problem. Something like "design a pub/sub queue with persistent delivery guarantees" or "build a logger with runtime-configurable routing." You have 90 minutes. Your job is to produce working, extensible, compilable code that a new engineer could extend without touching your core logic. Not boxes. Not pseudocode. Not "I would have a class here." Code.

Then, around the 45-minute mark, the interviewer adds a new requirement. A new vehicle type. A new log output. A new notification channel. If your design requires rewriting the core to handle this, the interviewer has seen what they needed to see.

Questions reported from recent interviews:

Design an in-memory SQL engine with table creation, deletion, and select/delete queries
Design a pub/sub queue with persistent delivery guarantees and ordering semantics
Build a logger that routes to different outputs based on log level and runtime configuration
Design a version control system similar to Git, with emphasis on extensibility
Design a parking lot for multiple vehicle types using factory and singleton patterns
Build a rating system with aggregation and sorting

These all share the same DNA: correct abstractions (interfaces, abstract classes, factory methods), SOLID principles under time pressure, and code that survives contact with a new requirement. The mid-session feature addition is not optional. It will happen. Your design either handles it gracefully or it does not.

Confirm your preferred language at the start. Razorpay's stack includes Go, Java, PHP, and TypeScript, and most interviewers are flexible on this.

LLD vs HLD: two different rounds testing two different skills

LLD tests whether you can build it. HLD tests whether you can design it. Candidates often show up prepared for one and surprised by the other.

What Gets Asked in the HLD Round

The system design round runs 60 minutes: 5-10 minutes of requirements, 40 minutes of design, 10 minutes of deep dives and trade-offs.

The distinguishing feature of Razorpay's HLD questions is that many are drawn from problems Razorpay actually solves in production. This is not "design Twitter" territory. These are fintech-flavored systems where the constraints are specific and the follow-up questions have right answers.

Questions seen across multiple candidate reports:

Design a notification system covering push, SMS, webhooks, and email
Design a distributed job scheduler that accepts cron expressions
Design a leaderboard system with caching
Design a fraud detection system for real-time transaction scoring
Design a quick commerce platform focusing on inventory and delivery routing

The notification system appears most frequently. It is a reliable test of whether you can think about fan-out, delivery guarantees, retry logic, and per-channel rate limits simultaneously. If you prep one HLD topic for Razorpay, start there.

For senior and staff roles, the HLD round goes deeper. Saying "use Kafka" without explaining partition key selection and consumer group design will get you stuck. The interviewer already knows what Kafka is.

The Payment Domain Tax

Razorpay processes payments at scale for hundreds of thousands of merchants. Engineers are expected to bring some domain fluency even if they've never worked in fintech before.

Think about what you are interviewing to build. Not imaginary URLs or hypothetical tweets. Systems that move real money. With legal consequences if something goes wrong and audit trails that regulators actually read. The bar for "thought about production" is higher than it is at a typical product company.

You do not need to have built a payment gateway. You need to know these four things.

Idempotency. Every write operation in a payment system needs to be idempotent. A merchant's server retrying a failed request should not create a duplicate charge. Razorpay's own APIs use idempotency keys, and interviewers will ask how you'd implement exactly-once semantics across services. If this concept has always felt a bit abstract, that gap will be visible in an interview where it is the first follow-up.

Rate limiting. Razorpay uses Nginx as a rate-limiting sidecar with a fixed-window counter backed by Redis. For flash sales, this is the first line of defense before traffic reaches application servers. Know the trade-offs between fixed window, sliding window log, and token bucket approaches.

Connection pooling. PHP does not natively support persistent database connections. Razorpay's production stack routes MySQL connections through ProxySQL, which maintains a warm connection pool and can cache query results. Knowing why this matters at scale signals that you have thought about production reality, not just algorithmic correctness.

Gateway routing. Razorpay routes transactions through multiple bank gateways and uses ML-based scoring to pick the one with the highest predicted success rate. If a system design question touches payment processing, discussing fallback routing and success-rate feedback loops will land well.

How the Bar Shifts by Level

SDE1: Evaluated on DSA correctness and basic LLD. The machine coding problem is typically smaller with more time to work through it. HLD is either skipped or treated as a conversation starter rather than a gate.

SDE2 is where both design rounds become independent filters. The reported rejection pattern is failing the LLD round despite passing DSA and HLD. Interviewers have described the bar as requiring "maturity equivalent to 5+ years" on design questions. Most candidates treat LLD as the warmup and HLD as the main event. This is exactly backwards.

Senior and Staff candidates face a longer HLD with operational depth. Interviewers want to see reasoning about monitoring, deployment, schema evolution, and failure recovery. The hiring manager round includes deeper project interrogation: the specific trade-offs you made and whether you would make the same calls again.

Five Things That Kill Candidates

Starting code before designing. The machine coding round is 90 minutes, which feels like 20 when you realize you need to rewrite your class hierarchy at the 50-minute mark. Spend the first 15 confirming the interfaces before touching the keyboard. If you skip this, you will redo work while the interviewer watches.

Treating LLD and HLD as the same round. They test different skills. LLD is implementation. HLD is architecture. Drawing boxes in the LLD round or writing pseudocode in the HLD round signals confusion about what is being evaluated. Both look confident from the inside and sloppy from the outside.

Skipping domain context in HLD. Designing a generic payment service without mentioning idempotency, retry logic, or ledger consistency is a red flag at a company whose core product is a payment gateway. It signals that you prepared for a system design interview, not this one.

Not writing working code. Multiple candidates report being rejected for providing "pseudocode rather than working code" in the machine coding round. The interviewer has seen a lot of pseudocode. Compile it mentally before presenting.

Ignoring extensibility. The mid-round feature addition is coming. It is always coming. If your design requires rewriting the core to add a new log output or a new notification channel, you have handed the interviewer the rejection signal they were looking for.

How to Prepare

Six weeks is enough for SDE2 if you are genuinely structured. Eight weeks is what "structured" looks like in practice for most engineers.

Weeks 1-2: DSA. Focus on graphs, trees, sliding window, and two-pointer problems at medium difficulty. Razorpay does not typically ask hard-tier math or bit manipulation. Graph traversal and interval problems appear regularly.

Weeks 3-4: LLD. Practice building systems from scratch in 90 minutes. Work through parking lots, hotel booking systems, pub/sub queues, and logger frameworks. The goal is not memorizing solutions but building the habit of interface-first design. Use SpaceComplexity to practice explaining your design decisions out loud, because the machine coding round is a conversation, not a silent sprint.

Week 5: HLD. Study the notification system, job scheduler, and fraud detection problems in depth. For each, practice the 60-minute format: requirements (10 min), high-level diagram (15 min), data model (10 min), scaling and deep dives (25 min). Read Razorpay's engineering blog for production context on the systems they actually operate.

Week 6: Payment domain and mock runs. Read about idempotency, rate limiting algorithms, and gateway routing. Do two or three full mock interviews covering both LLD and HLD back to back.

For the hiring manager round, come with two or three projects you can defend at the design decision level. Interviewers will probe why you made specific trade-offs, not just what you built. "The team decided" is not an answer.

For the complete picture of the Razorpay loop, including DSA format, behavioral themes, and offer details, see the Razorpay software engineer interview guide. For the payment system design problem itself, the payment system design walkthrough covers the full architecture. For fraud detection, which comes up frequently at Razorpay, the fraud detection system design guide covers the real-time scoring pipeline in detail.