In play markets

[ShaunWhite]

my tick to trade is sub 10ms.

Sat in a car doing 70mph that's under a foot of travel, for people like me who glaze over at micro and macro numbers.
Hats off to all involved in the software and infrastucture at every stage that's making that possible. The BF matching and liability engines must glow red hot, half of that time is just getting the message to them.

[PDC]

The 200ms order/processing limitation hasn’t been a thing for years (if it ever was), orders are processed as quick as Betfair can process them. And it is possible but there is some competition and it’s not easy.

Prior to streaming it was definitely a thing and still is if you use polling I believe. It wasn't originally 'a thing' but it was later introduced by Betfair to cache the data to 200ms as people were taking the piss and hammering the Betfair servers as fast as they could to get as up to date information as they could and this was causing issue for Betfair.

It is well documented on the forum as I have read a lot of the threads about it when deciding if I wanted to use streaming or not.

With the introduction of streaming and Betfair pushing the data rather than the user pulling the data it was no longer an issue and they don't cache the data at 200ms any more (though I don't know if they do it at say 20ms, perhaps Dallas will know?).

[LinusP]

The 200ms order/processing limitation hasn’t been a thing for years (if it ever was), orders are processed as quick as Betfair can process them. And it is possible but there is some competition and it’s not easy.

Prior to streaming it was definitely a thing and still is if you use polling I believe. It wasn't originally 'a thing' but it was later introduced by Betfair to cache the data to 200ms as people were taking the piss and hammering the Betfair servers as fast as they could to get as up to date information as they could and this was causing issue for Betfair.

It is well documented on the forum as I have read a lot of the threads about it when deciding if I wanted to use streaming or not.

With the introduction of streaming and Betfair pushing the data rather than the user pulling the data it was no longer an issue and they don't cache the data at 200ms any more (though I don't know if they do it at say 20ms, perhaps Dallas will know?).

You are confusing the marketBook requests per second limit (is a thing) and the myth that betfair only process orders every 200ms (fairly sure it’s never been a thing).

[spreadbetting]

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've run my own API bots for a long time and never had any delay to bet orders, you stick in the request and milliseconds later you get your bet response telling you how much has been matched etc no delay whatsoever. It's most likely the myth started due to the way most off the shelf API apps used to make the order and data requests at the same time limited to price data request constraints.

[PDC]

You are confusing the marketBook requests per second limit (is a thing) and the myth that betfair only process orders every 200ms

Yes, my mistake I miss-read it/didn't register the fact they were asking about process orders and not marketbook requests.

[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.