How Anypoint MQ Circuit Breaker Works

The circuit breaker pattern is similar to an electrical circuit breaker, which stops the flow of electricity to prevent overloads and fires when there is a problem. In software, a circuit breaker watches calls to an external service or system. If there are too many failures in a short time, the circuit breaker "trips" and stops more calls to the faulty service, giving a fallback response instead. This prevents overloading the failing system and helps the application continue working, though with reduced performance.

MuleSoft's circuit breaker pattern helps make integrations more reliable and robust by handling failures and reducing the impact of problems in the integrated systems. The Circuit Breaker has three different states, each affecting how the application behaves in specific ways:

Closed State:

Normal Operation: The application works normally, sending requests to the external service without interruption.
Monitoring: The Circuit Breaker keeps track of failures or errors that happen during this time.
Failure Threshold: If the number of failures goes beyond a set limit within a certain period, the Circuit Breaker moves to the "Open" state.

Open State:

Preventive Mode: In this state, the Circuit Breaker stops requests from reaching the failing external service.
Fallback Mechanism: Instead of sending requests, the Circuit Breaker activates a fallback response, such as using a cached response or redirecting to another service.
Recovery Timer: After a set recovery time, the Circuit Breaker switches to the "Half-Open" state to check if the service is back to normal.

Half-Open State:

Recovery Assessment: The Circuit Breaker allows a few test requests to the external service to see if it is working properly.
Outcome Determines Transition: Based on the results of the test requests, the Circuit Breaker will either go back to the "Closed" state if the service is working again or return to the "Open" state if the service is still having problems.

Circuit Breaker Configuration Properties:

Error Type:
Configures specific error identifiers that the Circuit Breaker should respond to. Custom errors can also be set up.

Examples:
HTTP: CONNECTIVITY
HTTP: TIMEOUT
APP: CUSTOM ERROR

Error Threshold:
Defines the number of errors allowed before the Circuit Breaker switches to the "Open" state.

Trip Timeout:
Specifies the recovery period after which the Circuit Breaker moves to the "Half-Open" state.

Trip Timeout Unit:
Sets the unit of time (e.g., minutes, seconds, hours) for the trip timeout period.

Circuit Breaker Operation:
Wraps a function call, monitoring for failures and acting when errors exceed the configured threshold.

Illustration of Anypoint MQ Circuit Breaker:
In this example, we'll show an integration flow using Anypoint MQ as the source via a subscriber, sending data to an external system with an HTTP request. We'll set up a global circuit breaker in the Anypoint MQ subscriber to handle potential failures efficiently.

The Anypoint MQ subscriber is built to manage standard queues where message order isn't crucial. Even FIFO (First In, First Out) queues can be managed with the right circuit breaker configurations to meet specific requirements.

In a test scenario where the external system endpoint is unresponsive and returns a connectivity or timeout error, the payload triggers a negative acknowledgment (NACK) in Anypoint MQ. This NACK stops the queue and retries the message, ensuring data integrity is maintained.

We’ve configured the circuit breaker with a threshold of 2 retries. If the external system stays unresponsive and exceeds this retry threshold, the circuit breaker shifts to an "open" state, preventing data loss.

After the set trip timeout, the circuit breaker moves to a "half-open" state and retries the request. If the external system is back online, the request is successfully processed, and the circuit breaker resets to "closed." However, if the system is still unresponsive, the circuit breaker remains in the "half-open" state until the next wait period.

In another scenario where a retry or fallback mechanism is needed at the process API level, the circuit breaker can effectively capture retriable errors based on responses from system APIs. This approach helps prevent data loss and ensures seamless operation by managing failures and implementing retries or fallbacks as needed.