# Five Years of Kafka at Razorpay's UPI Switch

DevFeed: [Five Years of Kafka at Razorpay's UPI Switch](<https://devfeed.tech/articles/five-years-of-kafka-at-razorpay-s-upi-switch-24044.md>)

Original publisher: [Read original article](<https://engineering.razorpay.com/tryst-with-kafka-2f5cef766c45?source=rss----6407ad2e59af---4>)

Author: Kshitij Nawandar

Published: 2026-09-07T09:09:58Z

Content type: article

Language: en

Sources: [Razorpay Engineering - Medium](<https://devfeed.tech/sources/razorpay-engineering-medium.md>)

Topics: [Kafka](<https://devfeed.tech/topics/kafka.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [event driven](<https://devfeed.tech/topics/event-driven.md>), [Amazon Simple Queue Service (SQS)](<https://devfeed.tech/topics/amazon-simple-queue-service-sqs.md>), [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Microservices](<https://devfeed.tech/topics/microservices.md>), [Amazon Web Services](<https://devfeed.tech/topics/aws.md>)

Tags: [aws](<https://devfeed.tech/tags/aws.md>), [aws-sns](<https://devfeed.tech/tags/aws-sns.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [event-driven](<https://devfeed.tech/tags/event-driven.md>), [kafka](<https://devfeed.tech/tags/kafka.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [razorpay](<https://devfeed.tech/tags/razorpay.md>), [redshift](<https://devfeed.tech/tags/redshift.md>), [sns](<https://devfeed.tech/tags/sns.md>), [sqs](<https://devfeed.tech/tags/sqs.md>)

## AI overview

Razorpay describes five years of evolution in its UPI Switch, from a monolith using AWS SQS to Kafka-based infrastructure. The article covers architectural decisions, operational challenges, and optimization work affecting payment-processing performance, reliability, and scale.

## Source excerpt

Preface The UPI Switch at Razorpay has evolved significantly in the five years since we started building it. The Switch is the platform that enables real-time payment processing with NPCI. When the team began, it was little more than an idea. Today it powers more than 70% of Razorpay's total UPI volume. Because UPI is inherently asynchronous, a messaging system sits at the heart of the Switch and has a direct impact on performance, reliability, and scale. What began as a straightforward queue became the core of the system, shaping how every new feature was designed and delivered. This post covers that evolution: the decisions that enabled growth, the ones that slowed us down, the operational issues that forced us to rethink our assumptions, and the optimizations that ultimately stabilized our Kafka-based infrastructure. This is the story of what we got right, what we got wrong, and how we eventually built something stable enough to grow on. The First Version: Monolith and SQS When we began building the UPI Switch, we weren't thinking about massive scale, distributed systems, or elegant event routing. So we built Switch v1 as a monolith. No microservices, no distributed orchestration: just one solid block of code doing everything. That was the right call. We needed to move fast, experiment, and learn, and we followed the Keep It Simple, Stupid (KISS) principle deliberately. For messaging, we picked AWS SQS: reliable, managed, and low on cognitive load. We didn't need ordering guarantees at the time, so a standard queue worked fine. We started with just two queues, and this setup held its ground. It handled a peak of 400 TPS during the IPL. The limitations showed up as the ecosystem grew. A single event, like a successful payment, needed to fan out into multiple workflows: Update NPCI with an API call Send callbacks to merchants about payment status Push structured data into our warehouse (AWS Redshift) To handle this, we started bolting on AWS SNS plus SQS for fan-ou