Kite 3 architecture and technical stack
Kite 3 is the third major version of Zerodha’s Kite trading platform, released in 2018 as a ground-up rewrite of the Kite front end and data layer. The rewrite replaced the jQuery-based implementation of the original Kite with a component-driven JavaScript architecture, introduced a binary WebSocket protocol for real-time market data delivery, and integrated TradingView’s charting library for technical analysis. Kite 3 serves as the current foundation for both Kite Web and the Kite Mobile app.
Background and motivation
The original Kite platform (released 2015-2016) was built on jQuery and used a polling-based mechanism for market data refresh. As the platform’s user base grew, polling created increasing server load and was inadequate for the low-latency data delivery required by active traders. The charting implementation in the original Kite was also limited in the range of indicators and drawing tools available.
The Kite 3 rewrite was documented in Zerodha’s Z-Connect engineering blog in 2018. Zerodha’s engineering team described the goals as: reducing initial page-load time, switching to a push-based data delivery model, and adopting a charting solution that could support professional-grade analysis without proprietary licensing constraints.
Front-end architecture
Kite 3’s browser application is a single-page application (SPA) delivered as a static JavaScript bundle over HTTPS from Zerodha’s CDN. The application hydrates in the browser after the initial HTML shell is loaded. The component architecture allows independent rendering of the watchlist, order window, chart panel, positions view, and holdings view without full page reloads.
The JavaScript bundle is transpiled and minified for production; Zerodha has not publicly disclosed the specific front-end framework (whether React, Vue, or a custom implementation) but engineering blog posts reference a component-based architecture with unidirectional data flow.
State management in the application follows a pattern where market data updates (streaming in from the WebSocket) propagate to subscribed UI components. Each instrument subscribed in a watchlist receives price updates that are diffed and applied only to changed fields, minimising DOM operations.
Binary WebSocket data feed
Kite 3’s most significant architectural change from its predecessor was the introduction of a binary WebSocket data feed. The WebSocket protocol (wss://) establishes a persistent connection between the browser (or mobile app) and Zerodha’s quote servers. Market data packets are transmitted in a compact binary format rather than JSON text, reducing payload size and parsing overhead on the client side.
The binary format encodes:
- LTP (last traded price): A scaled integer representing the price.
- OHLC (open, high, low, close): Previous day’s close and the current session’s open, high, and low.
- Volume: Total traded volume for the session.
- Average traded price: Volume-weighted average price for the session.
- Open interest: For derivatives, the current open interest and the change in open interest from the previous session.
- Market depth: Five best bid prices, bid quantities, offer prices, and offer quantities (in full-mode subscriptions).
- Last trade time and last traded quantity.
The WebSocket protocol is the same protocol exposed by the Kite Connect API, documented in the Kite Connect developer documentation. The Kite 3 browser application uses the same binary feed as external developers consuming Kite Connect’s WebSocket endpoint.
TradingView integration
Kite 3 replaced its earlier charting implementation with TradingView’s charting library, integrated as an iframe within the Kite Web application. TradingView’s library provides the chart rendering engine, the indicator computation logic, and the drawing tools. Kite provides the data: historical candle data is served from Zerodha’s own OHLCV candle store via a UDF (Universal Data Feed) adapter, and real-time tick data is streamed from the binary WebSocket feed through an adapter layer.
The UDF adapter translates Kite’s internal candle-data format into the format expected by TradingView’s charting library. TradingView’s charting library communicates with the UDF adapter via JavaScript callbacks within the iframe’s execution context; the data exchange is same-origin within the Kite Web application’s domain context.
Historical candle data for the TradingView chart is available at minute, hour, and day resolutions going back to 2000 for NSE instruments and further for BSE instruments, stored in Zerodha’s candle data infrastructure. The depth of historical data enables technical analysis on long-term charts without gaps for actively traded instruments.
Order management integration
The Kite 3 front end communicates with Zerodha’s order management system (OMS) via HTTPS REST API calls. The OMS is the back-end system that interfaces with NSE’s and BSE’s order entry gateways. Order placement, modification, and cancellation are REST operations. Exchange acknowledgements are returned in the REST response.
Post-trade events (fills, partial fills, rejections, status changes) are delivered to the Kite 3 browser client through the WebSocket channel in the order update frame format. This avoids the need for polling the order book for status updates, reducing latency of order status visibility in the UI.
Mobile adaptation
The Kite Mobile app uses the same back-end REST and WebSocket APIs as the web application. The mobile apps (Android in Kotlin, iOS in Swift) implement their own native UI layer communicating with these APIs. The TradingView charting library is used in its mobile variant for the charting component within the mobile app, adapted for touch interaction.
Historical candle data store
Zerodha operates its own OHLCV candle data store for the charting and historical data endpoints exposed via Kite Connect. The store ingests tick data from the exchange feed and aggregates it into candle intervals (1-minute, 3-minute, 5-minute, 10-minute, 15-minute, 30-minute, 60-minute, day, week, month). The historical data endpoints in Kite Connect serve data from this store.
Authentication and session management
Kite 3 uses a session token-based authentication architecture. On login, the client provides a user ID, password, and a TOTP (time-based one-time password) second factor. Zerodha’s identity service validates these credentials and issues a session token. This token is stored in the browser’s session storage and transmitted with every REST API call as an authorisation header.
The session token is shared between kite.zerodha.com and console.zerodha.com, enabling single-sign-on across the Kite trading terminal and the Zerodha Console back-office portal. Token expiry is set to approximately 07:00 IST the following day, requiring a fresh login each trading day. This design satisfies SEBI’s internet-based trading security requirement for session-level controls.
For Kite Connect API users, an OAuth-style three-legged flow generates per-user access tokens. The same session infrastructure underlies both the browser-based Kite 3 application and external API client access.
Order management system integration
Kite 3’s front end communicates with Zerodha’s order management system (OMS) through a REST API layer. The OMS performs pre-submission validation (margin check, instrument validity, order parameter validation) before forwarding the order to the exchange’s order entry gateway. The exchange gateway returns an acknowledgement containing the exchange order ID, which is returned to the Kite 3 front end in the REST response.
Post-trade events, fills, partial fills, order status changes, rejections, are pushed to the Kite 3 browser application through the same WebSocket channel that delivers market data. The order update frame in the WebSocket binary protocol carries the order ID, status, filled quantity, average fill price, and timestamp. This push-based notification eliminates the need for the browser to poll the order book endpoint repeatedly for status updates, reducing both server load and the latency of order status visibility in the UI.
For derivatives positions, the OMS computes daily mark-to-market (MTM) settlement amounts at the exchange’s end-of-day settlement price. These MTM credits and debits are reflected in the client’s ledger within Zerodha Console and affect the available margin displayed in Kite 3’s funds view the following morning.
Performance characteristics
One of the stated design goals of Kite 3, documented in Zerodha’s 2018 Z-Connect post on the rewrite, was reducing the initial page-load time to enable productive use within seconds of navigation. The static JavaScript bundle served from CDN, combined with browser caching of unchanged assets, allows returning users to load the application faster than first-time visitors.
The WebSocket binary protocol’s compactness means that a typical full watchlist of 50 instruments in full mode (five-level depth) consumes a fraction of the bandwidth that equivalent JSON text would require. This efficiency matters for users on mobile data connections or on broadband connections with high latency or variable throughput.
Zerodha has not published detailed benchmarks for Kite 3’s front-end performance characteristics. Engineering posts have described the architecture as optimised for the median Indian retail trading client, whose hardware in the 2018-2024 period ranged from mid-range Android smartphones to desktop PCs with 8-16 GB RAM. The SPA architecture avoids full-page reloads, reducing perceived latency during navigation between sections (watchlist to chart to positions).
Infrastructure and deployment
Kite 3 is served from Zerodha’s own infrastructure. The static front-end assets are distributed via CDN to reduce geographic latency for clients across India. The WebSocket quote servers are deployed at or near NSE’s co-location facility at Mahape, Navi Mumbai, and at other data centre locations, to minimise the latency between the exchange’s market data feed and Zerodha’s quote dissemination infrastructure.
Zerodha has described in public communications that infrastructure scaling was a significant operational challenge during periods of unusually high trading activity, such as major IPO listing days. The addition of WebSocket gateway capacity and OMS scaling are described in Z-Connect posts that followed the LIC IPO listing incident of May 2022 and the Tata Technologies IPO listing of November 2023.
See also
References
- Zerodha Z-Connect Blog. “Kite 3.0, the new Kite”. z-connect.zerodha.com. 2018.
- Kite Connect. “WebSocket binary format documentation”. kite.trade/docs/connect/. Accessed May 2026.
- TradingView. “Charting library documentation”. tradingview.com. Accessed May 2026.