I built trading systems for LMAX exchanges. Their technology seems quite far from the state of the art to me.
I didn't know they even claimed to attempt being the fastest exchange in the world. They're very far from being so and it's quite clear that there are architectural decisions in that platform that would prevent that.
I don't particularly know anything about this disruptor, and it being in Java kinda biases me towards dismissing it out of hand (no one does serious systems programming in Java).
From a quick reading it's just a standard spmc queue with some mpmc capabilities. Queues (preferably lock-free and bounded) are a basic component of any low-latency distributed software system. They seem to understand the basics right, nothing too outstanding, some decisions quite suboptimal.
Myself I use spsc task queues for inter-thread communication (because in that scenario you know who you're sending tasks to, and you can easily just attach multiple spsc queues for pseudo-mpsc capabilities), and mpmc message queues for inter-process communication (because that scenario is more of a message bus, and you don't know who's talking to who).
I have built these kinds of things many times together with bespoke threading and scheduling models, as have others at all of the trading shops I've seen, so I'd say it's a pretty standard thing in the industry.
Open-source frameworks of interest would be Seastar or DPDK.
However, while a good threading model helps, it's far from sufficient to be the highest performance trading exchange. You also need to think hard about networking, be it the protocols, the software, the hardware and the topology. For example key factors in trading are deterministically publishing data to all participants at the same time, ensuring private information is not published before its public equivalent, making sure that whoever sent their packet first gets processed first. Even something as simple as the kind of switches you use has a huge impact.
It is a broadcast queue. Consumers all receive the same data, so they don't contend to pop elements. And producers never wait for consumers. Slow consumers have to deal with missing packets.
At the end of the day, it is a specialised ring buffer that happens to be useful for many use cases.
That just sounds like a normal spmc queue as I said above.
Of course they receive the same elements, or it wouldn't be multi-consumer.
Of course producers don't wait for consumers, they don't even need to be aware of how many there are or where they are. But even in a system where you'd know (e.g. publishing data to a bunch a TCP connections), it would he a very bad idea to stall production -- handling back pressure should be application-specific.
You have the same elements in UDP multicast which is the network equivalent, and incidentally the preferred technology for communication in the trading industry, particularly for market data disseminated by exchanges.
Topically in an MC queue, a consumer "consumes" an element and won't be available for other consumers. For example a job queue. Also typically queues either grow unbounded or pushes fail.
So no, I wouldn't say that the disruptor is a normal SPMC or MPMC queue as it semantics are different.
But yes, it has pretty much the same characteristics of UDP.
I see what you mean. I would never use a pattern where you don't broadcast to all consumers myself.
And while you can fail to produce when a consumer is too slow, I'd argue that sort of pattern only makes sense for a single consumer as well (the network equivalent would be TCP, which by definition can only be unicast).
I didn't know they even claimed to attempt being the fastest exchange in the world. They're very far from being so and it's quite clear that there are architectural decisions in that platform that would prevent that.