I did try looking it up fwiw. That was my guess but I was wondering if you meant something else and didn’t want to jump to conclusions.
I was surprised by the suggestion that kdb+ was used for this because a matching engine doesn’t really sound like the kind of case that APL-family languages would be well suited to – they tend to work well on large batches of data but for a matching engine, you have messages that come in over time and you want to process each message with reliable low latency (if you have higher latencies you will get wider spreads which is a competitive risk and leads to collecting less in fees), which means not operating on batches.
Do you have a source for the claim that kdb+ is used for the matching engine?
Comments
I did try looking it up fwiw. That was my guess but I was wondering if you meant something else and didn’t want to jump to conclusions.
I was surprised by the suggestion that kdb+ was used for this because a matching engine doesn’t really sound like the kind of case that APL-family languages would be well suited to – they tend to work well on large batches of data but for a matching engine, you have messages that come in over time and you want to process each message with reliable low latency (if you have higher latencies you will get wider spreads which is a competitive risk and leads to collecting less in fees), which means not operating on batches.
Do you have a source for the claim that kdb+ is used for the matching engine?
I worked on that codebase personally but here is a write-up on it:
https://blog.bitmex.com/bitmex-technology-scaling-part-1/
https://kx.com/news/kdb-powers-trading-platform-bitmex-high-...
https://www.odbms.org/2017/09/use-case-kdb-integral-to-bitme...
It really works, and also the codebase is quite mindbending. There is a weird elegance to it but also huge lock in.