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.

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