Every trading day, lakhs of traders open Kite, pick a stock or an option strike, and tap buy or sell. The confirmation pops back almost instantly. Done. Most of us never think twice about it.
The tap to confirmation feels like a second or two, but most of that is the app, the taps, and the screen redraw. The order itself moves far faster. Punched from anywhere in India, the round trip to the exchange and back is well under 100 milliseconds, and the internal exchange facing leg is single digit milliseconds. So what really happens in that sliver of time? Where does the order go? Who checks it? Whether you are sitting in Salem, Surat, Shillong, or in the middle of nowhere with a decent internet connection, your order somehow 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.
Here is the full breakdown of that journey, the way Zerodha built it. Most brokers follow a broadly similar architecture, so this stays relevant no matter where you trade.
What happens the moment you log in to Kite?
When you log in, Zerodha routes you to a specific silo that was assigned to your account at signup, so your session lands in a predetermined data center every time.
Think of silos like lanes on a highway. Instead of every user piling onto one lane and causing a jam, the system splits traffic across multiple independent lanes. Each silo lives in a different physical data center. For example, silos A and B in Mumbai and silos C and D in Chennai. So by the time you finish your morning chai, your order already knows exactly which lane it will travel through, before the order itself even exists.
What is the first checkpoint an order hits?
The first stop is Cloudflare, a security layer that filters incoming traffic and blocks malicious requests like DDoS floods before they ever reach Zerodha’s servers.
When lakhs of users hit your platform daily, you also become a target. Bad actors can attempt a DDoS attack, flooding servers with millions of fake requests at once to overwhelm the system. Cloudflare catches and blocks that traffic before it does damage.
Here is the tricky part. Cloudflare sometimes gets it wrong. If your ISP has been flagged for suspicious activity, maybe too many requests from one location, Cloudflare can accidentally block legitimate users too. That is a false positive. Your order never makes it in, and from your side it just looks like Kite is down. So if every other app works fine but Kite refuses to load, this is often the reason.
Where does the order go after Cloudflare?
After clearing Cloudflare, the order enters Zerodha’s cloud on AWS, where load balancers spread traffic across servers and auto scaling adds capacity the moment demand spikes.
Like most modern tech companies, and plenty of large banks and financial institutions, Zerodha runs a big part of its infrastructure on Amazon’s cloud. The challenge AWS solves is volatility. On a normal day there are hundreds of thousands of users. On a budget day or during a major global event, that number can spike suddenly and sharply.
Two things keep the system standing. First, load balancers act like traffic cops at a busy intersection, distributing orders evenly so no single server gets overwhelmed. Second, unlike a physical server that you cannot expand on demand, AWS spins up new capacity in real time. AWS also runs across multiple regions in India, so if Mumbai has an issue, traffic can reroute to Hyderabad with barely any disruption.
How does the order travel from AWS to the data center?
It travels over P2P leased lines, private point to point connections that are faster and more reliable than the public internet, with the internet kept ready as an automatic backup.
Up to this point the order has lived entirely on AWS. Now it needs to reach a completely separate physical setup. Zerodha runs its own on premise data centers in Mumbai and Chennai. These are not cloud servers floating somewhere on the internet. They are physical, fortress like facilities, heavily secured, temperature controlled, with redundant power, maintained by NTT Global Data Centers (formerly Netmagic).
The link between AWS and these data centers runs on P2P lines, point to point leased lines. Think of a P2P line as a private expressway reserved only for Zerodha. No traffic, no sharing, just a direct high speed connection. And Zerodha never relies on a single line. The P2P line is primary and the internet is the backup. If the leased line has a problem, the system switches over automatically. There have been days when an ISP routing issue took a line down mid session and most users never even noticed.
What checks does the order go through inside the data center?
Inside the data center the order passes three gates: a lightweight in house pre filter, then the OMS that logs and assigns an order ID, then the RMS that runs margin and limit checks.
The journey through the data center looks like a series of security gates, each one validating the order before passing it forward.
The first gate is a mini RMS layer Zerodha built in house, sitting right at the entry point. This is a quick pre filter. Is the order within circuit limits? Is the exchange segment correct? Is the account active? It weeds out obvious problems early so they do not clog the system downstream.
If the order clears that, it reaches the big one, the Order Management System (OMS). Zerodha uses Omnesys, an industry leading OMS through which more than half of India’s orders flow. This is the most critical piece in the entire chain. Here your order is logged, assigned a unique order ID, and handed to the RMS, the Risk Management System.
The RMS is where the real scrutiny happens. Do you have enough margin? Is the order within permissible limits? All those silent background checks live here. That unique order ID, by the way, is the number Zerodha support refers to when you call about an order. It is the fingerprint of your order from this point on.
How does the order finally reach the exchange?
Once the RMS gives the green light, the order crosses another set of dedicated leased lines to the exchange, where every millisecond matters and capacity is measured in messages per second.
Like the AWS to data center link, the connection between Zerodha’s data center and the exchange (NSE, BSE, or MCX) is not the public internet. It is another set of dedicated P2P leased lines, because at this stage latency is everything.
These lines are not cheap. They are sized by the number of messages per second, not by bandwidth. To put that in perspective, a line supporting 5,000 messages per second costs around 2.5 crore for the primary and backup combined. Both NSE and BSE offer capacities up to 100 Mbps, and Zerodha currently runs a 100 Mbps line. That sounds tiny next to home broadband, but these lines only carry small order packets. No video, no images. So the headroom is more than enough for normal volumes. On extremely volatile days, when thousands of orders and fills fly back and forth at once, even these lines can get congested.
For resilience, Zerodha runs two physical lines to the exchange via two different ISPs, typically Airtel and TCL. If one fails, the system switches to the other automatically. If the switch does not trigger because a line is only partially working, a condition called flapping, the team intervenes manually.
At the exchange, a final round of checks runs. Is the market open? Is the order valid? Is the account recognized? If everything clears, the exchange accepts the order, stamps it with its own exchange order ID, and sends a confirmation back along the same path.
What do “Open” and “Complete” actually mean on your screen?
Open means your order has successfully reached the exchange and is sitting in the order book. Complete means the exchange has matched and filled your order.
And all of it, every step described above, happens in a few milliseconds.
What can go wrong along the way?
Plenty can fail at any point, but not all failures are equal. Most you will never notice because redundancies absorb them. A few are visible, and a rare few are genuinely disruptive.
Here is the spectrum, from least to most disruptive.
Failures you never feel. The P2P line between AWS and the data center goes down, and the system silently switches to the internet backup. AWS Mumbai has an issue, and traffic reroutes to Hyderabad automatically. These are exactly the scenarios the redundancies were built for.
Brief hiccups. A sudden traffic spike takes AWS a few seconds to auto scale. A Cloudflare false positive blocks a handful of users on one flagged ISP. These usually resolve in seconds or minutes, though Kite might feel slow or unresponsive for a moment.
Visible but manageable. An exchange leased line starts flapping, partially up and partially down, so the automatic switchover does not trigger. The team has to step in and switch manually. During that window orders can be delayed and you may see something like “open pending” on screen.
Genuinely disruptive. The OMS goes down, or the exchange itself has an outage. These are the rarest and the most impactful. When the OMS struggles, confirmations get significantly delayed. When the exchange has an outage, there is very little a broker can do beyond coordinating with the exchange and keeping users informed. These are the moments you see notifications on the Kite app and on social media.
The truth is, most of the time none of this surfaces. The redundancies do their job quietly in the background.
The full journey at a glance
Seven layers, hundreds of moving parts, multiple physical locations across India, all in a few milliseconds:
- Login and silo. You log in and the system routes you to your assigned silo.
- Cloudflare. Your order is screened for legitimacy.
- AWS. It is load balanced and routed across servers.
- P2P line to the data center. It travels a private leased line to Mumbai or Chennai.
- Internal checks. It clears the mini RMS, then the OMS, then the main RMS.
- P2P line to the exchange. It crosses another leased line to NSE, BSE, or MCX.
- Exchange validation. The exchange accepts it, stamps an order ID, and sends confirmation back.
The next time you open Kite, find your stock, and hit buy, take a second to appreciate what is happening under the hood. Hundreds of engineers, years of infrastructure work, and layer upon layer of redundancy, all working quietly so that you almost never have to think about any of it.
Credits
This explainer is based on the brilliant breakdown by S. Sandeep Rao, SEBI Registered Research Analyst (sandeeprao.co, ssr.smallcase.com) and host of The Long and The Short on the Zerodha YouTube channel. Sandeep walks through the journey of an order with rare clarity, and this article simply puts his explanation into written form for traders who prefer to read it.
