Reliability Pattern


Reliability pattern as the name suggest make the MuleSoft API/Application more reliable by providing the Transactional support when Non-Transactional transport is used in MuleSoft application. Think you are creating an API to receive payment and once you receive the payment information, if anything goes wrong then you are losing the payment and end up in losing customer experience also.

Non-Transactional transport like HTTP, File and SFTP doesn’t support transaction. Request received on such Transport can end up in message loss as if anything goes wrong within mule flow. To make such interaction more reliable this pattern can be used with connector which supports Transaction e.g. VM, JMS and DB. This will guarantee there is zero loss of messages and all request are process with at most reliability.

Transaction makes it sure the activities within the transaction will be executed as single unit. Think if we have two DB interaction within mule flow and one of them succeed and other fail then partial commit will happen but in can of transaction flow commit will happen in both or none. This will maintain the integrity of the integration.

Below flow show issue with Non–Transactional Transport like HTTP with transactional Transports like DB. If error occurs in second DB insert then there is no provision of doing a proper rollback and end up in partial commit.

Reliability Pattern


To make this reliable we can introduce a connector (which support transaction) to divide the transactional and non-transactional activities.


In MuleSoft application flow will look like


Sample Application – reliability-pattern-services

Reference blog – reliability-patterns


Thank you for taking out time to read the above post. Hope you found it useful. In case of any questions, feel free to comment below. Also, if you are keen on knowing about a specific topic, happy to explore your recommendations as well.
For any latest updates or posts on our website, you can follow us on LinkedIn. Look forward to connecting with you there.

Share this:
Notify of
Newest Most Voted
Inline Feedbacks
View all comments
3 years ago

You still need to handle transactions at DB operations. What if any insert operation fails?
You need to roll back that transaction, and retry to ensure zero message loss.