Zerodha System Design Interview: What the Bar Actually Tests

Zerodha runs 15-20% of India's daily trading volume. Their engineering team is roughly 30-50 people. Do that math. Then do it again, because the first result can't possibly be right. And yet.

This is not an accident. Zerodha is philosophically anti-bloat. A small, senior team doing the work of ten is the design. Which means when they hire for systems work, they're not adding headcount. They're adding force multipliers.

The system design round reflects that directly.

Why the Zerodha System Design Interview Is Different

Most system design interviews give you an abstract problem: design Twitter, design a URL shortener. Zerodha's round is domain-specific. You're designing for a stock broker operating under SEBI regulations, serving two million concurrent users during a market open, with real money flowing through every component you sketch.

Three constraints shape every question:

Real-time latency is non-negotiable. Zerodha targets sub-40ms response times for trading operations. Saying "I'd add a cache here" without specifying what cache, what invalidation strategy, and what your tail latency looks like at the 99th percentile is not a satisfying answer. It's where the conversation stalls.

Financial correctness isn't optional. An order management system that drops a message under load isn't a performance bug. It's a regulatory failure with SEBI's name on it. Interviewers expect you to think about failure modes before you're prompted, not as an afterthought when they push back.

The team is small on purpose. Zerodha runs a massive platform with a tiny headcount by design. They want engineers who think about maintainability and operational simplicity, not engineers who reach for complexity to demonstrate knowledge. Complexity here is a liability, not a flex.

What the Round Looks Like

One 60-90 minute session, typically in-person at their Bangalore office. It sits inside a loop with a DSA round and a culture conversation. The Zerodha onsite guide covers the full loop; the phone screen guide covers what comes first.

A senior or staff engineer runs the round. For principal-level hires, expect the CTO or a founding engineer.

The structure is open-ended: they give you a problem, you clarify requirements, you architect live. Candidates who get offers consistently show clear trade-off reasoning, unprompted failure mode analysis, and enough fintech domain knowledge to make the design concrete. There's no rigid scorecard, but those things dominate offer feedback.

The Questions You'll Actually See

The problems map directly to Zerodha's product. If you've used Kite, you'll recognize them.

Design a real-time market data streaming system. Zerodha delivers tick-by-tick price updates to millions of users during trading hours. The core tension: you can't fan-out every tick to every subscriber through a database. Interviewers want to see a pub-sub architecture (Kafka for ingestion and fan-out, WebSockets for browser delivery), a clear story about backpressure when subscribers can't keep up, and a plan for connection drops mid-session. The interesting edge case is what happens during a volatility spike when every user is watching the same five stocks.

Design an order management system. This is the hardest and most common question. Start with the state machine for a single order before you touch distributed architecture. The states: pending, placed, open, partially filled, filled, cancelled, rejected. Map what triggers each transition. Know what happens to a user's margin at each state change.

Stock order lifecycle: state transitions from pending to terminal states

Candidates who jump straight to microservices without defining state get redirected back to fundamentals. Gently. In the way that still means you're not recovering in time. Zerodha built their own OMS over 2.5 years. When they ask you to design one, they want to see that you understand why it took that long.

Design a watchlist and portfolio tracking system. Zerodha supports 25+ watchlists per user with up to 50 instruments each, real-time P&L, and family portfolio views. The constraint: prices change every second during market hours, but you can't push an update to every subscriber for every tick across every instrument. The answer involves smart aggregation at the edge, connection pooling, and knowing when client-side computation is cheaper than server-side push. Interviewers want to hear you articulate why.

Design the Kite Connect API rate limiter. Zerodha's developer API serves thousands of algo traders. Rate limiting here isn't pure abuse prevention. Exchange connectivity has hard limits, regulatory constraints exist on order frequency, and fairness between traders matters. The design question is how you enforce per-user limits without a centralized bottleneck that becomes a single point of failure.

Occasional questions: mutual fund transaction system (Coin platform), P&L reconciliation for end-of-day settlement, price alert notifications at scale.

What they don't ask: generic problems disconnected from fintech. If your prep is all social networks and file storage, you'll feel the gap.

How the Bar Shifts With Seniority

Level	What the round actually tests
Mid-level (2-5 yrs)	Can you decompose a fintech problem clearly? Interviewers probe domain awareness and trade-off reasoning. Depth on one system beats breadth across three.
Senior (5-8 yrs)	Can you handle real scale? With two million concurrent users at market open, you need to think about thundering herds, backpressure, and recovery unprompted.
Staff / Principal	Do you own the architecture? Expect questions about consistency guarantees, exchange protocol constraints, and irreversible decisions.

For senior candidates, this round is the primary filter. Candidate feedback consistently rates the system design difficulty at 5/5. Mid-level is approachable with domain preparation. Interviewers are described as direct but fair, and they appreciate intellectual honesty over bluffing. If you don't know how margin calculations work, say so. Bluffing through financial mechanics is a specific red flag in this domain.

How to Actually Prepare

Use the product. Open a Kite account or use their demo. Click through watchlists, look at the order placement flow, watch the portfolio view update in real time. Every feature you interact with is a design problem they've already solved, and may ask you to solve cold.

Read their tech blog before the interview. The Zerodha tech blog is unusually candid about real engineering decisions. They've written about their Kafka architecture, their WebSocket infrastructure, and the lessons from building their OMS. Interviewers recognize when a candidate has read primary sources versus recycled interview prep material.

Know the stack conceptually. Zerodha uses Go for performance-critical services, Python for internal tooling, MySQL and PostgreSQL for transactional data, ClickHouse for analytics, Kafka for streaming, and WebSockets for real-time delivery. You don't need to be a Go expert, but you should understand why a company at this traffic volume makes that call.

Practice the order state machine. Before your interview, draw the full lifecycle of a stock order: every state, every transition, every failure case. Map what a margin call means at each stage. This surfaces the complexity interviewers probe, and doing it in advance means you won't be discovering it live.

Know the regulatory constraints. SEBI requires audit trails for all orders, with mandatory retention periods. This shapes storage decisions in ways social media designs don't. Bringing it up unprompted signals domain seriousness.

Practice out loud under time pressure. You have 60-90 minutes to go from clarification to components to failure modes. Silent prep won't build that muscle. A voice-based mock with rubric feedback, like what SpaceComplexity provides, catches communication gaps and time management issues you won't notice practicing quietly.

For the overall Zerodha interview approach, the software engineer guide covers what's expected across all rounds.

Mistakes That Get You Filtered

Designing for FAANG scale. Zerodha doesn't need a globally distributed, multi-region order system. They need a low-latency, reliable one for the Indian market. Proposing a 12-region active-active Kafka cluster signals you spent a weekend watching system design YouTube and forgot to read the problem statement. The interview isn't testing how big you can dream. It's testing whether you can think.

Skipping domain fundamentals. Saying "I'd put orders in a message queue" without knowing what a partial fill means, or what happens to open interest when an order is cancelled, signals a gap that matters in fintech. Domain ignorance creates real bugs in financial systems. Real ones, with money attached.

Only discussing the happy path. Every system works beautifully in an interview. The database is always up, the network never partitions, and your queue never fills. Real financial systems disagree. Loudly. During market opens. In front of SEBI.

A dog sits calmly in a burning room, sipping coffee and saying "This is fine."

Candidates who skip failure mode analysis, summarized.

If you wait for the interviewer to ask "what happens if this fails," you've already signaled that failure handling is an afterthought. Bring it up yourself. This is the single behavior that most differentiates candidates who get offers from those who don't.

Vague consistency language. "Eventually consistent" in a trading context without qualification raises flags. Order state requires strong consistency. Analytics can tolerate eventual consistency. Regulatory audit logs need durability guarantees. Know which parts of your design need what, and state it explicitly.

Treating the round like a knowledge test. Interviewers aren't checking whether you've memorized distributed systems theory. They're checking whether you can reason under ambiguity and defend a design. Candidates who present one solution confidently and then crumble when challenged perform worse than candidates who acknowledge trade-offs from the start. See system design interview tips for how to structure that reasoning.