What to Expect in the Zerodha System Design Interview

Expect a design conversation built on Zerodha's own problems, rather than a generic whiteboard question. Reports describe technical discussions that start with systems you have built and then move into trading domain problems. Likely topics include live market data delivery, order placement at market open, end of day reconciliation, report generation at scale, and large relational databases. Zerodha runs Go services on self-hosted infrastructure with very large PostgreSQL deployments, so a design that assumes unlimited managed cloud services does not match how this team works.

Is There a Machine Coding Round?

No machine coding round is reported at Zerodha. A machine coding round is a timed session in which you build a small working program and are graded on the code itself, and several Indian product companies run one. At Zerodha the nearest equivalent is the practical take-home task, where a deliberately simple program is judged on structure and documentation rather than on speed. For the distinction between that style of round and a design discussion, see system design versus low level design.

The Question Types

Live market data delivery. Exchanges publish price updates continuously during market hours, so designing the path from the exchange feed to many connected clients is the signature problem here. It tests fan-out, which means sending one update to many recipients, and it also tests back pressure and dropped connections.

The order path. An order travels from the app to the broker's systems to the exchange, and a confirmation returns along the same path. This tests idempotency, which means that a repeated request does not create a second order, and it tests the risk checks that run before an order is placed.

End of day processing. After the market closes, trades are reconciled and statements are produced, and Zerodha has written publicly about generating more than a million signed PDF documents in minutes. This tests batch design, parallelism, and failure recovery.

Data at rest. Large relational tables of orders and trades raise questions about partitioning, indexing, archiving, and query cost, and Zerodha uses PostgreSQL at a very large row count, so these questions are practical rather than theoretical.

A Walkthrough: Design the Live Price Feed

Here is a high level plan for the signature question.

1. Requirements (5 minutes). Many users are connected during market hours, updates arrive continuously per instrument, and each client subscribes to a subset of instruments. Freshness matters more than delivering every single tick, so state that early.

2. Ingestion. One set of processes consumes the exchange feed and normalizes it, and this layer must stay small and fast, because any delay here is passed to every client.

3. In-memory state. Hold the latest price per instrument in memory, then serialize each update once and reuse that buffer for every subscriber, because repeated serialization is the usual cost.

4. Fan-out. Clients connect over WebSockets to a tier of servers, where each server keeps its own subscription lists and writes updates to its own clients, so capacity grows by adding servers.

5. Coalescing. If a client is slow, send the latest price rather than the full backlog, and say this out loud, because it shows that you understand which data can be discarded.

6. Market open. Traffic is not uniform, because the open and the close create the peak, so plan capacity for the peak and degrade gradually rather than suddenly.

7. Persistence. Write ticks to a separate store for charts and later analysis, and keep that write path away from the live delivery path.

What the Interviewer Grades

Simplicity is graded highly, because the team is small and operates what it builds, so a design with many separate parts to run is a weakness rather than a strength. Name the cost of each failure in money and in regulatory terms, and explain how the system is monitored and how an incident during market hours is handled. Defend your choices with reasons, because the questions follow your answers.

Common Mistakes in This Round

• Adding services for their own sake. Splitting the design into many services leads to the question of who operates each one, and a small team cannot operate many.
• Treating the exchange as optional. The exchange is the source of truth for orders and trades, so a design that trusts local state alone is wrong.
• Skipping reconciliation. Broking systems must prove their numbers afterward, so a design that covers only the successful case is unfinished.
• Designing for an average day. Volatile days and expiry days create the load that matters, so state your capacity plan in terms of the peak.
• Assuming managed cloud everything. Zerodha self-hosts much of its stack, so justify each external dependency that you add.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers queues, caches, and databases, which every answer above uses.
• Go deeper on the hard cases. Advanced System Design Interview, Volume II helps with replication, partitioning, and failure handling.
• Read the company's engineering posts. Their topics are the interview topics: logging, PostgreSQL, monitoring, and document generation at scale.
• Rehearse the walkthrough. Practice the seven steps above out loud, and keep the whole explanation under 40 minutes.
• See the full path. The design conversation is one stage of the Zerodha interview process, alongside the motivation question and the reply timeline.