It is quite fitting that another HN darling, Jane Street, uses similar architecture in their exchange(s).
Event input queue, fully deterministic matching engine, and an output queue. Plus importantly, a sequencer to guarantee that the events going into the input queue have a known order.
Aspects of their architecture and design decisions have been made public through their podcast series, Signals and Threads.[0]
This isn't even close to unique. I['ve worked at a few HFT/MM places that all had a similar architecture in place before LMAX wrote this. This, multicast rings, and other patters are copied a lot in the industry because they work well for the problem space.
I'm not surprised. And I think you nailed the reason too:
> copied a lot in the industry because they work well for the problem space
Finance as an industry could be described as ... incestuous. The people move around within the small circle of firms, so any architectural knowledge gets cross-pollinated quite rapidly. From what I understand, the disruptor pattern itself was reasonably well known in the academic circles well before LMAX wrote about it - but I'm not sure anyone had put publicly available numbers on a heavily optimised version before them. (FWIW, I use a simplified disruptor in one of my own projects because it works well and simplifies the overall design. )
We should also be honest about the technical challenges: there are very few as interesting problem spaces as an exchange or a low-latency MM.
So much hype for a lock-free MPMC ring buffer. If you're familiar with the concurrency literature you'll see that nothing here was novel even at the time.
java had a proper memory model and the busy wait was a novelty. iirc, it was used mostly in a single thread processing (i.e. consumer) for the main business logic like matching forex order.
Realistically aside the disruptor LMAX had an interesting way for fail over by replaying all the input to reach the state.
I think that -MC is misleading. It would imply anycast (like what you would use for a work distribution queue), but the disruptor is multicast, I.e. all receivers potentially receive all the data. It is also lossy, like UDP.
Is there any didactic implementation of the Disruptor / multicast ring available somewhere? I've been curious in working through some practical example to understand the algorithm better.
It is a ring buffer indeed, with publish serialization (on producer side) and normally a busy wait. It sort of doesn't work on some VMs due to scheduling. (I mean the busy wait w/o a backoff)
The big win is how it allows bulk processing while taking serialization dependencies into account.
So you algos reading market data messages and yank all that is there and apply them in bunk instead of trying to do each one individually.
And your logger that is storing all the messages to a file and/or db knows what messages the algo has processed and can grab all the messages up to that point so it is always writing as much as it can and current.
Readit News
Event input queue, fully deterministic matching engine, and an output queue. Plus importantly, a sequencer to guarantee that the events going into the input queue have a known order.
Aspects of their architecture and design decisions have been made public through their podcast series, Signals and Threads.[0]
0: https://signalsandthreads.com/
> copied a lot in the industry because they work well for the problem space
Finance as an industry could be described as ... incestuous. The people move around within the small circle of firms, so any architectural knowledge gets cross-pollinated quite rapidly. From what I understand, the disruptor pattern itself was reasonably well known in the academic circles well before LMAX wrote about it - but I'm not sure anyone had put publicly available numbers on a heavily optimised version before them. (FWIW, I use a simplified disruptor in one of my own projects because it works well and simplifies the overall design. )
We should also be honest about the technical challenges: there are very few as interesting problem spaces as an exchange or a low-latency MM.
Thanks!
Realistically aside the disruptor LMAX had an interesting way for fail over by replaying all the input to reach the state.
(Disclaimer: I wrote it.)
There's also a spec for a Multi Producer Multi Consumer (MPMC) Disrupter.
So you algos reading market data messages and yank all that is there and apply them in bunk instead of trying to do each one individually.
And your logger that is storing all the messages to a file and/or db knows what messages the algo has processed and can grab all the messages up to that point so it is always writing as much as it can and current.
There is a Ruby version that is also very readable: https://github.com/ileitch/disruptor
(Disclaimer: I wrote it.)