Episode 3: Messaging
In this podcast episode we talk about messaging and its role in the distributed systems. We discuss the benefits, as well as some of the difficulties that people commonly encounter while using messaging.
Please don’t hesitate to post your comments. All feedback is welcome and appreciated!
MP3 Download: Distributed Podcast, Episode 3
Episode references
- What is messaging
- Lokad Message Format
- Google Protocol Buffers and ProtoBuf-Net
- Race Conditions Don’t Exist and Podcast on CQRS, Race Conditions and Sagas
- Pat Helland and Papers
- PusSubHubbub
- Apache QPID
- RabbitMQ
- MSMQ
- NServiceBus
- Message Queue Evaluation Notes for Second Life (a great comparison of message queues)
You guys ripped through a whole bunch of solutions to the ordering problem in about two minutes. But you missed a really simple one: partial order.
An ideal queue is fully ordered. Messages will be removed in the order that they were added. But, for all the reasons you mentioned (and more), ideal queues don’t exist. All of your solutions were good ways of recovering when messages are removed out of order.
But a full order among messages is over constrained. As you pointed out, sometimes (in fact most times) for any two given messages, it doesn’t matter which came first. So instead of trying to achieve full order, define a partial order. When it matters that A came before B, keep track of it.
Every message can carry a reference to all messages that must have come before. Call these their predecessors. When the subscriber receives a message, it first makes sure that it has seen all predecessors. If not, it pulls them from the queue. They have to be there, because the publisher has to put all predecessors into the queue first.
There are several ways to have one message reference another. GUIDs are a common solution, if heavy handed. The trick is finding a queue infrastructure that supports both FIFO and random access.
You might be concerned that the number of predecessors can get quite large. In practice, I’ve not found that to be the case. Consider that the transitive property applies to partially ordered sets, and you can see why this is so. A message only references its direct predecessors.
Great show. Keep it up.
Michael, thank you very much for such extensive comment.
Personally I’ve never thought about this approach in CQRS/DDD architectures, but it sounds really interesting and more flexible, than simple sequence numbers. Will definitely keep that in mind while talking and designing in future.
Thanks again!
Thanks for the high quality and relevant content!
I look forward to more podcasts.
Keep up the good work!
VirtualStaticVoid, thanks for the kind words! We’ll try to keep it going.
Thanks for good podcasts so far keep it up.
One question though.
When you guys where talking about rabbitmq and oliver said that the messages where only one node.
Couldnt the rabbitmq shovel plugin be used to replicate messages to another node? with idempotent consumers subscribing both nodes
http://www.lshift.net/blog/2010/02/01/rabbitmq-shovel-message-relocation-equipment
not saying this the best solution just a possible option.
Jakob, thank you for the tip. I wasn’t aware of this option.
It will be an interesting option, when this plugin passes QA testing and (potentially) gets the official support.
Jakob,
The issue that I have is that if a single node dies, the messages are gone until the node comes back online–if it ever comes back up. My interest is that, at the moment the messages are pushed into the message infrastructure, they are synchronously replicated across more than one machine.
yeah I see your point.
Enjoyed the show and it has me thinking much about web hooks and messenging. This technique could be the way to push messages to clients not on the same subnet as the server. I have been looking at the reverse http spec to see if there is a way to use it in a client to facilitate push messaging. The big problem is with NATing on the firewall. It would be cool if a firewall could use some specials rules to inspect incomming headers then route to the appropriate client. Anyway sorry about ranting and keep the good work.
Hi again,
you did not spoke about WCF role (if it can play some) in messaging in CQRS/DDD. I’m missing something? In .Net 4.0 I thought is WCF really usable part of framework.
A.
Ales,
WCF is still a RPC-focused communications layer. Hence, it is not something that is recommended to generally use in CQRS/DDD solutions.
In my own limited experience, all production projects with WCF eventually got migrated towards more simple and less painful solutions (meaning – “more cheap” to develop and maintain).
Rinat
Thank you for your work. I’m a newbie on cqrs and ddd and I am learling a lot from you guys. I actually decided to learn cqrs by writing my own implementation.
If we are going to persist all the events somewhere, and I understand it would be idial be able to persist the commands as well, and since messages are either commands or events, why not publish the message directly on our persistence infrastructure? Sooner or late we will have to pay the cost of persisting either events or commands.
I might be quite naive here, given my little experience, just wanted to know your opinion on the matter.
Thank you again for your great work!
The EventStore does just that–it basically a marriage between a database and a message queue. We commit to the EventStore and then it takes responsibility for calling out and publishing/dispatching the associated messages to all interested parties.