Authored by Sameer Padhan, Integration Architect
Messaging is a pragmatic solution that enables the communication between distributed systems that is loosely coupled.
Sending a message does not require both systems to be up and ready at the same time.
The integration systems are available most of the time. But what happens when either of the Sender or Receiver Systems Fails?
In this article, we will be discussing two points of failure.
How to solve when the Messaging system fails?
As soon as we hear messaging system has crashed, the only thing that comes to our mind is if we have original messages persisted somewhere so that we can re-process once the messaging system is back online.
The Persistence of the messages is the solution here.
Most of the Integration Platforms such as MuleSoft, Oracle FMW, etc. offer Java Messaging Service (JMS) Solutions with an option to make the messages “persistent” with a specific time duration.
For example, if we have set messages to be persisted for 4 hours, as soon as the messaging system is down, we will start getting warnings and errors (as configured). If we get notifications that messaging system will be up within an hour or two, we can re-process the same messages. In case it’s a bigger failure and will take more than hours to fix the messaging system, then we can and must download/export the persisted messages to the local secured server and re-process once the messaging system is up.
In many cases, persisted messages if failed to process the very first time, will try to re-process automatically for the required number of times as given in the retry mechanism.
How to solve when the Backend application fails?
There will be scenarios when the messaging system/brokers pick up the messages from the producer and try to deliver the messages to the backend system, but due to the failure of the backend system, it will not be able to deliver the messages.
We cannot return the messages to the producer; it may stress the producer system and integration systems should always be loosely coupled.
In this case, we should have a mechanism at the backend server end to consume the messages from the messaging system and free up the producer and messaging system.
Object Store comes to play in these scenarios. Messages will be consumed and can be stored in the object store temporarily. And once the backend system is up and running, it should consume the messages from the object store and then clean up the object-store.
This ensures messages delivery reliability and at the same time data remains intact.
Please let me know your views in the comments.