Cracking the Razorpay Backend Engineer Interview
Backend Engineers at Razorpay build the critical infrastructure that processes millions of financial transactions per day. The interview process is notoriously difficult, focusing on high-level system architecture, database ACID properties, idempotency, and distributed systems.
Phase 1: Advanced Data Structures & Concurrency
Before designing systems, you must prove you can write optimal, thread-safe code.
- The Focus: Expect Medium to Hard LeetCode problems (Arrays, Dynamic Programming, Graphs).
- Concurrency: This is crucial for fintech. "Implement a Thread-Safe Singleton." "How do you handle the Producer-Consumer problem using wait() and notify()?" You must deeply understand locks, mutexes, and thread pools.
Phase 2: Database Design and Internals
Razorpay relies heavily on data consistency; losing a transaction is unacceptable.
- Database Internals: You must understand how databases work under the hood. "Explain the difference between Read Committed and Serializable isolation levels."
- ACID Properties: Expect deep questions on transaction management. "What is a distributed transaction? Explain the Two-Phase Commit (2PC) protocol or the Saga pattern."
- SQL vs. NoSQL: "When would you use Redis vs. DynamoDB vs. PostgreSQL for a payment gateway?"
Phase 3: High-Level System Design (The Decider)
This round defines your level (SDE II vs. SDE III).
- The Scenario: "Design a highly available Payment Gateway API."
- Key Components to Discuss:
- High Availability & Circuit Breakers: How do you ensure the system stays up when a downstream bank's API fails? (Hint: Retry queues, Exponential backoff, Circuit breaker pattern).
- Idempotency: "If a user’s network drops after clicking 'Pay', and they click it again, how do you ensure they aren't charged twice?" (Crucial concept: API Idempotency using Redis or database constraints).
- Scalability: How do you scale the database to handle extreme loads during festive sales? (Hint: Database Sharding).
Top 3 Technical Questions to Prepare
- Explain how you would design an Idempotent API for processing payments. What database constraints or caching mechanisms would you use?
- Explain the concept of Optimistic vs. Pessimistic locking in a database. Which one would you use for a highly concurrent transaction ledger?
- Design a distributed Rate Limiter that allows a maximum of 100 API requests per minute per merchant API key.



