Message bus design - support implicit ordering of messages?

Question

One important design decision that needs to be made when designing a corporate message bus is whether (and how) the message bus should support implicit ordering of messages. By implicit ordering, I mean the ability to deliver messages in exactly the same order as they were sent.

There are several options:

• Don't support implicit message ordering at all. Messages are not guaranteeed to be delivered in the same order they were sent. Any business process that needs message ordering has to provide an explicit order within each message. This option simplifies message bus architecture, enables better scalability and recovery, and forces applications to adopt explicit message ordering.
• Have an optional layer in the message bus (above the transport layer) that provides messsage ordering only for those business processes that require it. This keeps the transport layer simple and scalable, but also gives the benefit of message order where appropriate. This is a similar design to FIX (which provides ordering) and FIXT (which doesn't provide ordering).
• Build implicit ordering directly into the transport layer of the bus. This removes the need for a separate ordering layer, but hinders scalability and recovery scenarios.

As an architect of a message bus, or as a developer who might use a message bus, which option do you prefer and why?

Answer 1

Your second option seem to offer the best of all worlds:

• when ordering is not required, we benefit from simple architecture and scalability.
• when ordering is required, it is only developped once, and not for each application.

If performance problems appear later, the unique implementation can be changed easily.

Answer 2

Providing total order of messages will require quite high overhead from the bus, so going with the second option is a good idea. However, flexibility many times comes with a cost of complexity for the bus user, thus in case the bus will be used FIX almost always, it might be a good idea to build the ordering functionality in bus directly. Later on you can provide lower layer API to send unordered messages. This is the third option.

In my opinion, the first option can be dropped no matter what. :)