In play markets

[ShaunWhite]

I've never heard of Betfair having order processing limitations, it just wouldn't make any sense for them to stack orders to process or even delay order responses. The price data requests used to be limited but actual bets have always been processed as quick as Betfair can handle them.

I think this is where it's come from ...

I've often seen people obsess about getting in the fast ping, but Betfair has been 200ms for a long time negating the benefit of high speed. An arms race developed early on when Betfair didn't cache and Betfair decided to change the way the exchange worked to stop that ever happening again and allow them to control the expense side of the equation in terms of how the exchange works.

Perhaps people assumed he was talking about orders when it was actually about polling for prices. But imo a fast ping is always a benefit, you want to be at the front of the line even if the doors haven't opened yet.

Looking at the doco sb posted in an earlier message, I take it to mean that when using the polling api, prices are updated every 200ms from an orders system that's running without delay. I'm not sure what the max frequency of market messages is for an inividual selection is though via the stream, I'm pretty new to all this.

How does the Betfair API cache data?
The two relevant types of caching we use are: .a delta caching
•caches that are updated by an external mechanism (external to that cache) aka delta caching.
•caches that are updated by some internal mechanism (internal to that cache)

Delta Cache
The API servers cache pricing data using a delta cache. Whenever any event occurs on the exchange (matching a bet, cancelling a bet, etc.) that changes pricing data, the exchange pushes an update to the cache. This cache is, therefore, always as up to date as possible. Updates to all API servers happen at the same time, so no API server is ever out of date regarding pricing data.

The exchange itself matches and processes bets on a ~200ms cycle and any changes are pushed to the delta caches. This means, of course, that if you request pricing data less than 200ms after a previous change, you cannot possibly get a different response as the exchange would not have completed a bet processing cycle. at return pricing data are using the delta cache and are always as live as possible.

All API calls that return pricing data are using teh delta cache and are always as live as possible.

Other Caches
Change on the exchange that are not as common are cached using a polling mechanism. For example, when a runner is removed there
are quite a few things that need to happen in the system as all unmatched bets on the runner need to be identified and cancelled, all matched bets need to be identified and voided, the funds need to be made available to user's account etc. before the runner can be physically
removed from the market. Suspending a market follows a similar pattern of events.

[LinusP]

Interesting, however that sort of caching looks to have been replaced along with the 200ms processing cycle. It’s not mentioned in any of the APIng docs and streaming confirms that orders aren’t processed in 200ms cycles anymore.