Dear developers, A few months ago, I'd made a detailed post describing our plans to rebuild the core APIs from scratch (replacing our vendor TR's solutions with our own). We've been hard at work at this, and I'm pleased to announce that we have made significant progress and have achieved impressive results.
In our benchmarks, the API connectors we're building outperform our vendor's by several orders of magnitude. For example, we're able to serve a fairly large order book (~100 orders) over HTTP in under 50ms. Our solution is also able to handle 20 to 30x more requests per second with a single process on a single server without any latency penalties or timeouts. In addition, the new architecture is also highly scalable and fault tolerant.
Over the next several weeks, we hope to replace our vendor's connectors with our own, in a phased manner. So, very soon, the Kite Connect APIs (and the Kite trading platforms) should become noticeably faster, stable, and highly reliable. This has become possible only because of the unprecedented low-level access to the OMS TR has given us, which we previously, never had.
Once this deployment is complete, we'll start releasing several enhancements we've been planning for the Kite Connect APIs.
In addition to this, Zerodha is making major investments in creating a new disaster-scenario setup (geographically separate data centre) as a contingency plan to be prepared for unlikely, but possible disaster events.
Could You Pls confirm the below...? 1. Present Setup Kite Client --> Kite Server --> TR OMS --> Exchange
2.Future Release Kite Client --> Kite Server --> Exchange
If second one is the case then, it is really awesome, this will beat the Pi/Nest Trader as those are still rely on TR. Please give more weightage to Scalability since most of the problem with TR is that it is not scalable during peak time and stuck when it receives more request.
Many Brokers have large client base, But Only Zerodha has Large Active Client Base which results in large number of order request hitting OMS.
@botany02 The future setup will still be using core TR OMS which is pretty solid as per our test but the issue we had till now was the XML api layer they had written top of the OMS which was a huge bottleneck for our current setup. As per our early tests we achieved at least 10x improvement in the speed and more stability.
@vivek Thanks for the Clarifications. So TR OMS is stable but only their API's (XML,COM(Used by Pi) etc) having issues, Kite Connect will use own XML API instead of what provided by TR. Is there any progress going on COM API also...?
With the speed up in latency and more volume handle capability, would you consider increasing the api call limitation (3/sec) to something more flexible like 5/sec?
Also - would it be possible for you to add a features in api calls to accept list wherever applicable instead of single order_id? For example kite.orders() to take list of orderids? It used to be slow and cause failure for large orderbook. However, I hope this will be improved a lot with the new setup in place.
Another feature request: kite.order_cancel is one of the api call which would be a big beneficiary in case of a) several orderids are passed in a single call b) increased request/second threashold.
@Kailash@vivek@sujith As you guys already tempted us with news about the update; and it's already near march end; can you guys give us any updates regarding the same?
@malay Around 60% our API is already moved to the new system. Calls like orderbook, holdings and positions are now served from our new API and in a month or so it will be migrated completely.
Will await final release.
Great Work...!!! Keep doing....!!!
Could You Pls confirm the below...?
1. Present Setup
Kite Client --> Kite Server --> TR OMS --> Exchange
2.Future Release
Kite Client --> Kite Server --> Exchange
If second one is the case then, it is really awesome, this will beat the Pi/Nest Trader as those are still rely on TR. Please give more weightage to Scalability since most of the problem with TR is that it is not scalable during peak time and stuck when it receives more request.
Many Brokers have large client base, But Only Zerodha has Large Active Client Base which results in large number of order request hitting OMS.
Congrats Once Again...!!!
Thanks for the Clarifications.
So TR OMS is stable but only their API's (XML,COM(Used by Pi) etc) having issues,
Kite Connect will use own XML API instead of what provided by TR.
Is there any progress going on COM API also...?
Keep up the good work!!!
With the speed up in latency and more volume handle capability, would you consider increasing the api call limitation (3/sec) to something more flexible like 5/sec?
Also - would it be possible for you to add a features in api calls to accept list wherever applicable instead of single order_id? For example kite.orders() to take list of orderids? It used to be slow and cause failure for large orderbook. However, I hope this will be improved a lot with the new setup in place.
Another feature request: kite.order_cancel is one of the api call which would be a big beneficiary in case of a) several orderids are passed in a single call b) increased request/second threashold.
Please create new thread for queries as it can help others also who are looking for the same query.
As you guys already tempted us with news about the update; and it's already near march end; can you guys give us any updates regarding the same?
OMS - Order management system which connects broker to exchange.
TR - Thomson Reuters is our OMS vendor.