How to Pass the Zerodha Backend System Design Interview

Zerodha stands out in the Indian tech ecosystem not just because they bootstrapped their way to billions in revenue, but because they pulled it off with a shockingly lean engineering team. When you walk into a backend interview here, don't expect to just regurgitate textbook microservice architectures. They want to see a deep appreciation for radical simplicity, self-hosted open-source software, and raw, pragmatic problem-solving. If you're gearing up for their system design round, you've got to know how to build systems that juggle massive concurrency and razor-thin latency without hiding behind unnecessary abstraction layers.

The absolute heartbeat of Zerodha's business is its trading engine. Processing millions of orders a day—especially during chaotic market hours—demands a system that doesn't just blindly scale horizontally, but is ruthlessly optimized for single-node performance. We're going to walk through the exact architectural patterns, algorithms, and trade-offs you need to master to ace this specific system design interview.

The Zerodha Hiring Process and Interview Rounds

Before we get into the architecture itself, you need to understand exactly how Zerodha evaluates candidates. Their hiring process leans heavily into practical coding and core computer science fundamentals, rather than abstract brain teasers. They'll test your ability to write clean, concurrent code and probe how well you understand what systems are actually doing under the hood.

The Core Problem: Designing a Low-Latency Stock Brokerage Engine

During the system design round, the most common scenario you'll face is building the core order routing and execution pipeline. The prompt usually revolves around a system that lets users place stock orders, validates their margins (available funds and holdings) in real-time, routes the order to the exchange, and streams the execution status right back to the user.

Throughput is tough, but latency is the real killer here. In financial systems, a delay of just a few milliseconds can mean a user gets a significantly worse price. You have to design a pipeline that ruthlessly minimizes network hops, strips disk I/O out of the critical path, and absorbs violent traffic spikes the second the market opens.

"How do you design a system to process millions of orders with sub-millisecond latency?"

Faced with this question, most candidates instantly start drawing a massive web of microservices talking over HTTP. In a low-latency environment, that's a fatal mistake. HTTP overhead and constant network serialization will completely destroy your latency budget. Instead, you should pitch a streamlined, modular monolith—or a tightly coupled set of core services that talk over persistent TCP connections or highly optimized message buses.

A standard, high-performance order execution flow should center around these core components:

• Order Gateway: The entry point that accepts WebSocket or REST connections from the client, runs basic schema validation, and drops the request onto an internal memory queue.
• Order Management System (OMS): The brain of the operation. It handles the order's lifecycle, runs margin checks, and decides if the order is actually valid to hit the exchange.
• Execution Management System (EMS): The adapter layer that translates your internal order formats into the specific protocol the exchange demands (like FIX protocol). It also manages the physical TCP connection to the exchange's matching engine.

"How do you handle real-time margin checks without slowing down order execution?"

This is easily the most critical bottleneck in any brokerage system. Before an order ever reaches the exchange, the system has to verify that the user actually has enough cash to buy, or enough shares to sell. Querying a relational database like PostgreSQL for every single order is way too slow. Under high concurrency, it'll lock up almost immediately.

To fix this, you have to introduce an in-memory state engine. During the interview, you can definitely propose using Redis to store user balances and holdings. Since Redis is single-threaded, it handles atomic operations beautifully using Lua scripts. That guarantees concurrent orders from the exact same user won't trigger nasty race conditions.

But if you want to push for ultra-low latency, take it a step further. Discuss handling in-memory state management directly within the application process itself. By using a language like Go, you can partition users across different goroutines. Each user's state gets protected by a local mutex or managed via Go channels, which completely eliminates the network hop to Redis. This in-memory state becomes your source of truth for the trading day, while changes are asynchronously flushed to a persistent database like PostgreSQL for eventual consistency and disaster recovery.

"Which message broker should we use for ultra-low latency pub/sub?"

When data has to move between the OMS, the EMS, and the user-facing market data streamers, candidates almost always blindly suggest Apache Kafka. Kafka is fantastic for high-throughput, durable event streaming, but it's rarely the right choice for sub-millisecond, real-time message routing. The disk I/O and ZooKeeper/KRaft overhead just add too much lag.

Zerodha is well known for heavily relying on NATS and NATS JetStream. In the interview, explain that NATS is a pure, in-memory pub/sub system written in Go. It runs on a fire-and-forget model for market data, which delivers vastly lower tail latencies than Kafka ever could. For order state updates that actually require durability, you'd use NATS JetStream. Highlighting this exact trade-off—Kafka's heavy durability versus NATS's lightweight, low-latency routing—will score you massive points.

"How do you store and query billions of trade records efficiently?"

A busy brokerage generates an unbelievable amount of data: order trails, execution logs, ledger entries, and endless market tick data. No single database technology can handle all those access patterns efficiently. You'll need to propose a polyglot persistence strategy.

For transactional data like user accounts, financial ledgers, and end-of-day balances, PostgreSQL remains the gold standard. It gives you the strict ACID guarantees you need when dealing with money. To scale Postgres, talk about table partitioning by date for the ledger, and definitely mention connection pooling using tools like PgBouncer.

For analytical data—think historical trades, charting data, and market ticks—row-based databases fall flat. Instead, pitch an OLAP database like ClickHouse. Because it's a columnar database, ClickHouse can ingest millions of rows per second and compress the data heavily. It lets the frontend query years of historical candlestick data in mere milliseconds. Mentioning ClickHouse aligns perfectly with Zerodha's actual tech stack, and it proves you understand the fundamental difference between row-oriented and column-oriented storage.

How to Ace the Zerodha Onsite

Passing their system design round is just as much about your engineering philosophy as it is about your technical chops. They want engineers who build simple, robust, and highly maintainable systems.

• Avoid Buzzword Bingo: Don't suggest Kubernetes, Kafka, or microservices unless you can strictly justify why they're better than a simpler alternative.
• Embrace Open Source: Get familiar with self-hosted FOSS tools. Explaining why you might choose HAProxy over an AWS Application Load Balancer shows you actually understand infrastructure.
• Focus on Concurrency: Be ready to talk about how your system handles race conditions. You need a solid grasp of locks, semaphores, and lock-free data structures.
• Acknowledge Failure: Hardware fails, networks partition, and exchanges drop connections. Always bake a disaster recovery plan and a reconciliation process into your design to fix broken state.

If you focus on low-latency principles, in-memory state management, and deeply pragmatic technology choices, you'll be more than ready to tackle the toughest questions their engineering team throws your way.