Razorpay broke its monolith into microservices, and everyone remembers it as a "modernization." The actual trigger was an IPL season where a flood of traffic forced them to throttle their own paying merchants.
In 2019, gaming and food-delivery surges during the Indian Premier League hit Razorpay's payment monolith hard enough that the only lever left was to slow down merchants — the worst thing a payments company can do during the moment merchants are making money.
A monolith is one big application where every feature shares the same process and the same fate. Convenient to start with. The problem: when one feature gets slammed — say, payment creation during a flash event — it starves every other feature of resources, because they all live together. You can't add capacity to just the part under pressure; you have to scale (and risk) the whole thing.
Splitting into microservices means each capability runs as its own service that can be scaled, deployed, and fail independently. The goal isn't speed. It's isolation.
Razorpay decomposed the monolith in phases — carving out payments, refunds, settlements, and more into independent services — rather than attempting a risky big-bang rewrite. Around the new architecture they layered the controls that actually tame spikes: autoscaling plus pre-provisioning ahead of known events (you can't autoscale fast enough for an instantaneous IPL surge, so you pre-warm), cache TTL with jitter to prevent synchronized expiry stampedes, and event-driven queues to absorb bursts asynchronously instead of forcing everything through synchronous paths.
Worth knowing
The phased approach is the quiet wisdom here. A big-bang monolith-to-microservices rewrite is one of the most reliable ways to destroy a company's quarter. Razorpay extracted services incrementally, keeping the system shippable throughout — the same caution Figma and Notion showed in their migrations. Evolution beats revolution when the system is load-bearing.
The gap it reveals
"Microservices scale better" is a half-truth that hurts juniors. The real insight is that microservices buy fault and resource isolation — the ability to scale and protect the hot component independently — at the cost of new distributed-systems complexity. Knowing that the IPL fix was pre-provisioning and queues (not merely 'splitting the monolith'), and that the migration must be phased, is the operator's view.
In the interview room
If you propose microservices in a design round, the sharp follow-up is "what does that actually buy you here, and what does it cost?" Strong answer: independent scaling and blast-radius isolation for the hot path, paid for with network calls, distributed transactions, and operational overhead — plus pre-provisioning for known spikes since autoscaling lags. That balance signals you've run this, not just read about it.
The reframe
Architecture decisions are rarely about elegance; they're about which failure you're trying to prevent. Razorpay didn't want microservices — they wanted to never again throttle a merchant because an unrelated feature was on fire. Name the failure first, and the architecture chooses itself.
Microservices aren't a speed upgrade. They're a blast-radius decision.
Primary source →
Nirakar Asha on Medium — How Razorpay Rebuilt Its Payments Platform: From Monolith to Microservices