Imagine it is 9:15 AM on a Monday morning. Millions of traders across the country tap "Buy" or "Cancel" on apps like Zerodha or Groww at the exact same fraction of a second.

If an exchange used standard web servers and typical database setups, the entire market would crash within seconds under the weight of incoming web traffic. Yet, the exchange processes over 100,000 orders every single minute—matching buyers with sellers in under 10 microseconds—without ever dropping an order or double-selling a stock.

Here is the exact blueprint of how high-frequency matching systems achieve microsecond execution at scale.

Before breaking down every piece, here is how an order moves from a trader's app down to physical fiber lines, CPU cores, and post-trade clearing:

NSE and stock brokers don’t use traditional REST calls, instead they communicate via Binary TCP protocols transmitted using Kernel Bypass network cards. Stock exchanges have their backend located in the same data center as NSE. Also these backend servers are connected via physical cables. It helped stock exchanges and NSE to communicate in microseconds

Also to communicate they use kernel bypass network cards over TCP. When a regular computer sends a network packet, the standard OS network stack (the Linux Kernel) handles the transmission. This "context switching" between your application and the OS kernel adds too much latency (5–15 microseconds). In Kernel Bypass network cards, the broker’s custom C++/Go application writes the raw binary packet directly into the network card’s memory space. The network card immediately transmits the electrical/optical signal down the wire, bypassing the entire Operating System kernel.

To handle orders placed on such a large scale and execute them in real time can’t be handled using a permanent store. So any order placed is stored in memory as well as in permanent storage. NSE matching engine core relies purely on distributed cache

Also along with putting order specific data in cache, it is also stored in persistence stores. A synchronous, low-overhead journaler appends the raw event sequentially to non-volatile storage (NVRAM/NVMe). If the server fails, it reboots, reads the last consistent state snapshot, and then replays every sequential event from the NVMe log

This is the core engine that is responsible to execute the orders matching the buy/sell price. It uses price time priority data structure, where orders are stored sorted by price and time. So it maintains two separate binary trees. One for buy order that is sorted in descending order of price and one b-tree for sell order sorted in ascending order of price

Buy b-tree is in descending order because if the current price is 100 then any order placed for price higher than 100 is eligible to buy. Sell b-tree is in ascending order because that is best suitable price for buyer to purchase. Also for one price there can be multiple orders, so for each price these orders are stored in a doubly linked list based on FIFO. So any new order for the same price is added to the end of the linked list. And whenever matching price is triggered, order is executed from head of linked list

How does order executes

Orders are executed based on buy and sell price. So to execute an order at O(1) buy b-tree is sorted in descending order and sell b-tree in ascending order. So any new buy order is placed. It is checked against the first element of the sell tree if it is greater than sell price then order is executed else it is placed in b-tree. Same when sell order is received, it is matched against root of but b-tree

Once an order is executed, it is communicated back to brokers via TCP wire immediately. Now brokers send event notification back to client app via web socket communication. Also all executed orders are sent to NSDL/CSDL in the end of the day so that stock pools can be updated for client and money transfer can also take the place

What is the biggest challenge for real time stock trading, that you think should be solved? Share your thoughts over email.

Cheers,

Tech Builder