Using the NServiceBus distributor and few workers doesn’t change things when in-order message processing is considered: If the client sends the messages in a batch, they are processed in-order. All the messages in one batch are processed by one of the workers and only by using one thread.
Here’s a screenshot from our distributor sample application when the client calls Bus.Send for each message using the “Register users” –link (messages are not batched):
Like discussed previously, ##### represents a handled ChangeUserEmailAddressCommand-message and ***** represents the handled CreateUserCommand-messages. We would like the CreateUserCommand-message to be processed before the ChangeUserEmailAddressCommand-message. In our first example this is not happening.
The picture is completely different when the two messages are sent in a batch:
As you can see, the distributor disposes the messages to the workers in the same batches as they were sent by the client.
When the worker2 is configured to have more than one thread (by changing the NumberOfWorkerThreads), output is again substantially different:
Even though the output is different, the end result is same: The messages are processed in the right order.
If your server’s workload is getting too high, it’s reasonable easy to to plug in the NServiceBus distributor and all the required workers. You can do this without changing anything on the client’s side. This allows you to scale-out your system when needed.