Messaging is the essential concept in the word of application integrations. That is why it is so important to do it properly.
Following picture describes the correct messaging pattern:
When we need to integrate two applications using messaging, we have several options how to do it. In this post I want to explain how to make this integration reliable. As you can see, the topology is based on two separate messaging brokers, local and remote. Each of the applications then connects to its own broker locally. This is the key because local call is much more reliable than the remote call. Following picture shows a typical messaging pattern with just one broker.
The main difference between these two patterns is that in the case of just one broker one of the applications must connect to it remotely. In the case when the remote broker is down the client has no option how to deliver the message and should fail. On the other side having its own local broker eliminates this issue almost completely. Broker may be embedded in the application or deployed on the same host as a sidecar. In the second option the broker is accessible through reliable localhost interface.
There are at least two main options how to connect brokers:
- bridge – bridge is a common built-in functionality of the most messaging brokers. Use this option when you want to send messages to the other broker in their original form. More complex topology with multiple brokers is called a broker network.
- ETL – you can use an ETL flow to extract a message from one broker and push it to the other. This option should be preferred in the case when you need also to transform messages.