Welcome to the midweek edition of The Long and the Short—a show where you can expect an honest take on trading. Something you won’t hear elsewhere. I’m Sandeep Rao.
Every single day, lakhs of traders log into Kite, find their stock or their options strike, and hit buy or sell. Done. Two seconds. Order placed.
But what actually happens in those two seconds?
Where does that order go? Who checks it? Whether you’re sitting in Salem, Surat, Shillong, or the middle of nowhere with a decent internet connection — that order travels all the way to an exchange in Mumbai, gets validated, gets matched, and comes back to you as a confirmed trade. Every single time.
What are all the moving parts that make that possible? And what are all the things that could go wrong?
I sat down with the infrastructure team and basically made them explain the whole thing to me. Honestly — it blew my mind. So that’s what this edition is about: a full breakdown of the journey of an order, from the moment you tap that buy button on Kite, to the moment the exchange says yes, done, complete.
It’s specific to how things are built at Zerodha, but most brokers work in a broadly similar way — so this should be relevant to you regardless of where you trade.
Stop 1 — Logging In (It’s More Than You Think)
Let’s start where we all start every morning — logging into Kite. Most of us think logging in is just logging in. You type your credentials, do your 2FA, and you’re in. Simple.
But the moment you hit that login button, something important is already happening in the background.
At the time you created your account, Zerodha mapped you to a specific silo — and every time you log in, that’s exactly where you land. Think of silos like lanes on a highway. Instead of all users piling into one single lane and causing a traffic jam, the system splits users across multiple independent lanes.
Here’s what’s interesting: each silo is actually housed in a different physical data centre. Silos A and B are in Mumbai; C and D are in Chennai. Four completely different locations.
So by the time you’ve finished your morning chai and are ready to place your first trade, your order already knows exactly which lane it’s going to travel through — and all of that happens before we even talk about the order itself.
Stop 2 — Cloudflare (The First Checkpoint)
You’re logged in, you’ve put your stock on the watchlist, and you hit buy. The moment that happens, your order leaves your phone or laptop and travels across the internet. And the very first thing it runs into — before it even gets close to Zerodha’s servers — is a checkpoint called Cloudflare.
Cloudflare is essentially a security guard. Its job is to figure out if the incoming request is legitimate.
When you have lakhs of users hitting your platform every day, you’re also a target. Bad actors on the internet can attempt something called a DDoS attack — flooding your servers with millions of fake requests all at once, trying to overwhelm the system and bring it down. Cloudflare catches all of that and blocks it before any damage is done.
But here’s where it gets tricky: Cloudflare can sometimes get it wrong. If your ISP — say Airtel or Jio — has been flagged for suspicious activity, Cloudflare can accidentally block legitimate users too. A false positive. Your order never even makes it in, and from your end it just looks like Kite isn’t working.
So if you’ve ever had a moment where every other app is working fine but Kite just won’t load — this could actually be the reason.
Stop 3 — AWS (The Brain of the Operation)
Past Cloudflare, your order enters AWS — Amazon Web Services. Yes, Zerodha, like most modern tech companies, runs a large part of its infrastructure on Amazon’s cloud. Some of the biggest banks and financial institutions in the world do the same.
Here’s the challenge AWS has to solve. On a normal day, Zerodha has hundreds of thousands of users placing orders. On a volatile day — a budget announcement, a big global event — that number can spike dramatically and very suddenly. So how does the system not buckle under that pressure?
Two things. First, load balancers — think of these like traffic cops at a busy intersection, distributing incoming orders evenly across multiple servers so no single server gets overwhelmed. Second, unlike a physical server that you can’t magically expand, AWS can automatically create new capacity when traffic spikes. It scales with demand in real time.
One more thing worth mentioning: AWS doesn’t run everything from one location. They have servers across multiple locations in India. So if there’s an issue with the Mumbai infrastructure, AWS can automatically reroute traffic to, say, their Hyderabad servers — with barely any disruption on your end.
Stop 4 — The Physical Data Centre
Up until now, your order has been handled entirely on cloud infrastructure. But now it needs to travel to a completely separate, physical setup.
Zerodha has its own dedicated, on-premise data centres in Mumbai and Chennai. These are not cloud servers sitting somewhere on the internet — these are physical servers housed in buildings, maintained and secured by a company called NTT Global Data Centers (previously known as Netmagic). Fortress-like facilities: heavily secured, temperature-controlled, with redundant power supplies. More secure than most government offices.
How does the order actually get from AWS to the data centre? Through what are called P2P lines — point-to-point leased lines. Think of a P2P line like a private expressway that Zerodha has exclusively for itself. No traffic, no noise, no sharing with anyone else. Just a direct, dedicated, high-speed connection between two points — much faster and more reliable than the regular internet.
And equally important: Zerodha doesn’t rely on just one line. There are always two paths available. The P2P line is primary, and the internet acts as a backup. If the P2P line has any issues, the system automatically switches to the internet connection. There have been instances where ISP routing issues caused a line to go down mid-trading day — and because the switchover is automatic, most users never even felt it.
Stop 5 — Inside the Data Centre (Three Layers of Checks)
Inside the data centre, your order goes through a series of checks — like a series of security gates, each one making sure your order is valid before letting it through to the next.
First: The Mini RMS. Zerodha has built its own pre-filter layer that sits right at the entry point. Before your order even reaches the main order processing system, it quickly checks the basics — is this order within circuit limits? Is the exchange segment correct? Is the account active? A quick sanity check that filters out obvious problems early, so they don’t clog up the system further down.
Second: The OMS — Order Management System. Zerodha uses an industry-leading OMS called OmneNest. More than half of India’s orders flow through this particular OMS. This is the most critical piece of infrastructure in the entire journey. Everything happens here — your order is logged, assigned a unique order ID, and then passed to the RMS.
Third: The RMS — Risk Management System. This is where the real scrutiny happens. Do you have enough margin? Is your order within permissible limits? All those checks that happen in the background when you place a trade — that’s the RMS doing its job.
Every order that successfully enters the OMS gets a unique order ID assigned to it. If you’ve ever called Zerodha support about an order, this is the number they’re referring to. It’s essentially the fingerprint of your order from this point onwards.
Once the RMS gives the green light, your order is finally ready for the last leg of its journey.
Stop 6 — The Exchange
Your order has now cleared Zerodha’s mini RMS, the OMS, and the RMS — all green. Now it’s ready for the final leg: the stock exchange — usually NSE, BSE, or MCX.
Just like the connection between AWS and the data centre, the connection between Zerodha’s data centre and the exchange is not the regular internet. It’s another set of dedicated P2P leased lines — direct, private, high-speed. At this stage, every millisecond matters.
These lines are not cheap. Zerodha pays a significant amount to the exchanges — particularly NSE — for this connectivity. Interestingly, the lines are billed on the number of messages per second, not bandwidth.
A line that supports 5,000 messages per second costs around ₹2.5 crore for both the primary and backup lines combined. Both NSE and BSE offer up to 100 Mbps capacities, and Zerodha is currently on a 100 Mbps line. That might sound like nothing compared to your home broadband, but remember — these lines are only carrying tiny, byte-sized order packets. No videos, no images, nothing else. The capacity is more than sufficient for normal trading volumes.
On extremely volatile days — when thousands of orders and fills are flying back and forth simultaneously — even these lines can get congested and cause small delays.
And if a line goes down completely? Zerodha has two physical lines to the exchange, serviced by two different ISPs — typically Airtel and TCL. If one goes down, the system automatically switches to the other. If the automatic switchover doesn’t happen — say the line is partially working, what’s called flapping — the team manually intervenes and switches it over.
Once your order hits the exchange, the exchange runs its own set of checks: Is the market open? Is the order valid? Is the account recognised? If everything checks out, the exchange accepts the order, stamps it with its own exchange order ID, and sends back a confirmation. That confirmation travels all the way back through the same path — exchange to data centre to AWS to your phone.
If you see your order as OPEN , it has reached the exchange. If you see COMPLETE , it has been filled.
The Full Journey — Seven Layers
- You log in → the system recognises your assigned silo.
- You place your order → it leaves your device and hits Cloudflare.
- Cleared by Cloudflare → on to AWS, load-balanced across servers.
- Travels via a dedicated P2P leased line → to Zerodha’s physical data centre in Mumbai or Chennai.
- Inside the data centre → passes through the mini RMS, then the OMS, then the RMS.
- Cleared by all three → sent via another leased line to the exchange (NSE/BSE/MCX).
- Exchange validates, accepts, stamps it with an order ID → confirmation comes back → you see OPEN or COMPLETE.
Seven layers. Hundreds of moving parts. Multiple physical locations across India. And it all happens in a few milliseconds.
What Can Go Wrong?
Not all failures are equal. Most you’ll never even notice. Others will have you refreshing Kite wondering what happened. From least to most disruptive:
Failures you’ll never feel. The P2P line between AWS and the data centre goes down? The system automatically switches to the internet backup. AWS Mumbai has an issue? Traffic reroutes to Hyderabad automatically. These are the failures that the redundancies are specifically designed for, and they work.
Brief hiccups. A traffic spike on AWS can take a few seconds to auto-scale. A Cloudflare false positive that blocks a handful of users from a specific ISP. Usually resolved in seconds or minutes — you might notice Kite being slightly slow or unresponsive for a brief moment.
Visible but manageable. The exchange leased line starts flapping — partially working, partially not. The automatic switchover doesn’t trigger because the line isn’t fully down. The team has to manually intervene and switch to the backup. This takes a few minutes, and during that window, orders might be delayed. You may see “open pending” on your screen.
Genuinely disruptive. The OMS goes down. Or the exchange itself experiences an outage. These are the rarest — but also the most impactful. When the OMS has an issue, order confirmations can be significantly delayed. When the exchange has an outage, there’s very little anyone on Zerodha’s end can do except communicate with the exchange and keep users informed. These are the situations when you’ll see Zerodha’s notifications on the Kite app and on social media.
The truth is — most of the time, you’ll never know any of this is happening. The redundancies do their job quietly in the background. But on the days something does go wrong, you may experience minor delays, or in cases of significant impact, you’ll get notifications about what’s happening.
So the next time you open Kite, find your stock, and hit buy or sell — take a moment to appreciate what’s happening under the hood.
Your order travels from your phone — wherever you are — across the internet, through Cloudflare, load-balanced across AWS servers, via dedicated leased lines to a physical data centre in Mumbai or Chennai, cleared through three layers of internal checks, shot across another leased line to the exchange, validated, accepted, and confirmed. And comes back to you.
All of it made possible by hundreds of engineers — some inside Zerodha, many more outside — years of infrastructure work, and a lot of redundancies built to quietly do their job every single trading day.
Most of the time, you never have to think about any of it. And that’s pretty much the point.
If you have any questions — about anything covered today, or anything else — drop them in the comments. They all get read.
Thank you, and see you in the next one.