The Disruptor pattern was developed at LMAX to solve the problem of exchanging information between different processing stages, and do it much faster than traditional approaches.
Knowing that “there is no such thing as a free lunch”, most of the questions we get try to focus on the how and where is the trade off?
In the next few blogs I’d like to give my take on it and where I think the “magic” is.
Some of the key ideas in the disruptor are tiny details that end up giving big results.
Others, are fundamental concepts that I believe should be applied to every software problem.
This will definitely not be a primer or a user’s guide to the disruptor
I’ll start in this blog with a few big ones:
Separation of concerns.
or to be precise: The right separation of concerns for the problem we’re trying to solve.
If I had to choose one key idea this would be it. Obvious, once you think about it… but absolutely critical.
The separation of concerns between coordination between multiple producers, coordination between multiple consumers and the shared memory storage between the two groups, allows us to optimise easily in scenarios where there are no multiple producers or when there are no multiple consumers.
By using a queue implementation out of the box which concerns itself with more than just this particular problem, we pay to overhead of always assuming the worst case scenario.
Mechanical sympathy
Not tuning your solution or implementation to the underlying VM / OS / hardware will cost you an overhead and many times its a really big one.
Again, obvious once you think about it, I mean, Would you read from a stream without a buffer? well – too often you find a code that does just that.
In exactly the same way – would you give more work to your garbage collector when you can avoid it? Not when latency is a concern.
The disruptor pattern shows more mechanical sympathy then most.
In the next blog I’ll focus on some of the tiny details in its implementation that do exactly that.