Hi @Sujith, I would like your feedback on what is our usage model versus what is your expected usage model on using historical data . Please help us align with your expected usage model : I am trying to understand your rational of limiting access rate to 2 to 3 requests per second and seeking to understand if i can align with that. What i feel is your perceived scenerio of usage by customers Or atleast given the rate limit how one can atmost use it : 1) Fetch a historical data of a stock 2) derive technical analysis and plot 3) Do manual analyse . 4) Repeat above steps for next stock. This way you expect your customers dont need to access historical data of more than 2 to 3 per second.
My usage scenerio and believe this is how most would like to use going by the the number of requests from your customers to increase the rate of historical data - 1) Every Fixed interval , Say every 30minutes interval i.e at 9.30, 10.0 , 10.30...(some may do 1 min/5min) 2) Fetch historical data for missing candles . Say , current time is 10.30 , my database has record upto 9.30 , then i would request for 30min candles from 9.30 to 10.00 and 10 to 10.30 (note that it is not just always the latest candle assuming my system might go down due to say network interruption etc) 3) Save these candle info to database . 4)repeat (1)(2)(3) for N stocks . Say 1000 stocks. 5) Do technical analsysi of these N stocks and save to database . 6) Apply filters to determine buy/sell signal for the stocks . I would expect that in these usage scenerio steps 1 to 5 completes very fast say within 3 to 5 mins which i assume is reasonable for the trade signals generated to be relevant. Given your rate limiting of 2 to 3 per second this is impractical . I can actually do only 1 request per second as i will have to keep aside request bandwidth for simultaneous trade transactions (on another process/thread). I hope you are able to see the problem . You definitely have a valid reason to rate limit , but you need to help us align our usage model with your expectation . May be architecting your APIs such that it always you to differentiate from a real usage scenerio versus abuse of your system. One thing you can do is to allow multiple stock requests in historical data requests (like you added in #3.0 revision of market live quote) . Your feedback and solution to the problem is highly appreciated.