The reason that we started to work with NServiceBus a few years ago, it that we always have pretty demanding integrations in e-commerce systems where real time in combination with disconnection between different systems is important for the customer experience as well as the demand for up time and stability. The advantages we have seen with NServiceBus is the simplicity in getting the basic structure to work, and instead the focus can be on design of the messages, and mapping of these to respective system. The management of the local storage of messages, and distribution to other nodes simply works. We also think that the bus model is well suited where we apply it, since we often have same messages that are consumed and created by different systems, where respective system is responsible for different parts of the message. Avoiding several direct connections between respective systems, but instead adding a message to the bus is therefore worth a lot.
Built-in error management with retransmissions and queues built up locally at respective node to later be transferred to other nodes, makes the systems tolerable to network disturbances or since a receiving system is down for maintenance, or even an unplanned one. When all systems works as planned, the update between the systems is quickly carried out, which makes the effect just as good as real time connections.
Since the exchange between systems is through messages, it also makes it possible to manage it parallel in a good way. If the time for execution is a problem in one node, you can easily add another node to read the same type of message, and these then share the work load. This is something that is extra important to extract all power from today’s CPUs with several cores.
A few tips that we shared during the seminar were to:
- Have in mind creating optimal business messages.
With this we mean that the design of the message shouldn’t be from a certain system, but rather based on how you describe an object in an optimal way in your business. For example, what is needed to describe an order, a customer, or a product in your business. Start from there when the message is created. Every node, then need to map this to their target system. The advantage with this design is that the systems are easy to change over time, without changing other systems/nodes.
- Have in mind that keep the number of dependencies between messages or a sequences between them to a minimum.
Since messages don’t have to arrive in the order that they are sent, as a part of sending them parallel, or the error handling above, it is important to avoid that a message only can be read if the previous message has been taken care of. Where it is still dependencies, it is important that the cases where messages are out of sequence, are handled in a good way.
If you have questions on how to start working with this type of bus integrations, you are welcome to get in touch to talk more about this.
