In-order messaging a myth?
I got this question the other day from one of my long-time readers Bill about nServiceBus and I thought I’d share:
I have a question around processing of messages in proper order. When leveraging multiple threads to process messages in a message queue, it is possible for the second message in the queue to get processed before the first - especially if the first message is considerably larger than the second. I have taken a lot of care to make sure that messages are sent in the correct order, only to find that the receiving system can process them out of order anyway.
Consider a Policy Created notification, which must come before a Policy Approved notification. If both messages are sitting in the queue when the receiving service starts up, the approval message can be processed before the creation message. How can I make sure that message ordering is respected by the receiving system? I am using WCF/MSMQ as the underlying transport by the way. The only way I have found so far is to limit the receiving service to a single thread, which is by no means desirable.
Well, the solution is really quite simple (at first).
If you’ve received a message that you think has arrived out of order, just call:
and that will put the message back at the end of the queue.
Once you start considering the fact that you don’t know when the first message is supposed to arrive, you might turn to using a saga (aka, workflow) to handle the logic. The saga would store the policy id, and then allow for N round-trips, before it decided that something bad had happened (like the Policy Created message getting lost), and then it could forward that to an operator, or possibly contact the first system and ask for a replay of the policy created message - or whatever automated fault resolution protocol you like.
In other words, message ordering is probably more trouble than its worth.