Paolo ArdoinoVerified account

1/3 I should, at some point, make a small tutorial about matching engines. You can write a really really simple one in few lines of code. ZMQ-input -> matching (2 red black trees per symbol) -> ZMQ-outputhttps://twitter.com/IvanOnTech/status/1213877073992933376 …

2/3 Then how you make it resilient, super-scalable, micro-second fast, ... it's all about art. I spent quite sometime in developing @bitfinex 's one, via many iterations and experiments. Now it's a beautiful beast, capable of incredible performance and powering several products!

3/3 Many exchanges rely on traditional databases to handle matching. This is why during peak market activity they won't perform well and throughput is heavily limitated. Of course it requires to develop custom fault-tolerance, resilience, ... but it's simply the only correct way.

Cool. But only if I can write a response on why all current matching and reporting breaks or fails to meet expectations in the most commonly used tech stacks in crypto under load.

Indeed. It shall be comprehensive

Very surprised to read 'exchanges using traditional databases for their matching engines'.

Yeah it's what happens when you get a bunch of web 2.0 guys who think they can solve a problem with "the cloud man" and "nodejs"

I would have thought, to deal with the throughput, especially sub second updates, something like in memory data grids, or kafka streams would be the first thing they think of