High Availability and Disaster Recovery
High availability (HA) and disaster recovery (DR) strategies protect your Mule applications from downtime caused by infrastructure failures, disasters, or maintenance. The right approach depends on how you deploy Mule runtime engine: managed platforms such as CloudHub 2.0 and CloudHub build in much of the resilience for you, whereas deployments that you operate—Runtime Fabric, Hybrid Standalone, and on-premises servers—require you to design clustering, failover, and backups yourself.
Understanding Downtime
Downtime strikes at any time, from any direction, and in any form, whether you plan for it or not. Keeping an organization operational during a technology outage, a facility loss, a personnel loss, or a third-party service failure prevents irreversible damage to the business. As organizations shift to e-commerce models that depend on 24/7 uptime, HA and DR increasingly determine their financial health.
Even small amounts of downtime add up and hurt an organization:
| Percentage Uptime | Percentage Downtime | Downtime Per Week | Downtime Per Year |
|---|---|---|---|
99% |
1% |
1.68 hours |
3.65 days |
99.9% |
0.1% |
10.1 minutes |
8.75 hours |
99.99% |
0.01% |
1 minute |
52.5 minutes |
99.999% |
0.001% |
6 seconds |
5.25 minutes |
High Availability Versus Disaster Recovery
-
High availability (HA) - Measures a system’s ability to remain accessible when a component fails. You implement HA by building multiple levels of fault tolerance and load balancing into a system.
-
Disaster recovery (DR) - Restores a system to an acceptable previous state after a natural disaster (flooding, tornadoes, earthquakes, fires) or a man-made disaster (power failures, server failures, misconfigurations).
Both strategies increase overall availability, but they differ in one key way: HA generally preserves the service with no loss, whereas DR preserves the data but usually incurs a brief loss of service while the DR plan runs and the system restores.
Creating Effective SLAs
A Service Level Agreement (SLA) defines what counts as acceptable service.
High availability means the service stays up, functions correctly, and processes requests and responses properly. It doesn’t mean the service always runs at full capacity. Systems that you design for high availability prevent outages and protect against interruptions. The SLA sets expectations for every stakeholder.
An effective SLA does these things:
-
Eliminates single points of failure
-
Redirects and handles traffic
-
Detects failures
For example, a basic service might define these SLAs:
-
Normal operation handles 1,000 transactions per second with 1-second response times.
-
Total downtime per year stays at or below 0.5 percent, or 1.83 days.
-
Minimum acceptable service handles 100 transactions per second with 1-second response times for up to 2 hours a week.
For details, refer to:
Disaster Recovery
How quickly can your company get back to work after an IT emergency?
Disaster recovery (DR) restores a system to an acceptable previous state after a natural or man-made disaster. To drive your DR plan, use measurable business requirements such as Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
DR centers on your RPO and RTO. RPO is the point you return to after a disaster. For example, if you back up the system every 24 hours, your RPO is at most the previous 24 hours. RTO is how quickly you restore to your RPO and resume business, which includes the time to bring backup infrastructure or applications online when your primary environment fails.
Backups form a major component of a solid disaster recovery program. Recovery comes in three types: cold, warm, and hot.
| Term | Definition | Example |
|---|---|---|
Recovery Time Objective (RTO) |
How quickly do you need to recover this asset? |
1 min? 15 min? 1 hr? 4 hrs? 1 day? |
Recovery Point Objective (RPO) |
How fresh must the recovery be for the asset? |
Zero data loss, 15 mins out of date? |
High Availability and Disaster Recovery by Deployment Model
HA mechanisms and DR responsibilities differ depending on how you deploy Mule. Each deployment model has a primary HA mechanism, a DR strategy and responsibility split, and a level of cross-region support. Use these differences to pick the right approach for how you run Mule.
| Deployment Model | Primary HA Mechanism | DR Strategy and Responsibility | Cross-Region DR (Runtime Plane) | When to Use |
|---|---|---|---|---|
CloudHub 2.0 |
MuleSoft runs multiple replicas across availability zones automatically. |
You own the multiregion strategy and provide a bring-your-own (BYO) global load balancer. MuleSoft manages in-region resilience. |
Supported through the Global Deployment entitlement, which MuleSoft provides. |
Fully managed, multi-replica resilience on AWS. |
CloudHub |
MuleSoft runs multiple workers across availability zones automatically. |
You own cross-region failover. MuleSoft manages in-region resilience. |
Not built in. You design and run cross-region failover. |
Fully managed, multi-worker resilience on AWS. |
Runtime Fabric |
You run a minimum of two replicas across availability zones, with optional Horizontal Pod Autoscaling (HPA). |
You own backup, restore, and failover to a standby cluster. |
Not built in. You fail over to a standby cluster in another region. |
Kubernetes-based clusters that you operate. |
Hybrid Standalone |
You cluster runtimes to share memory and fail over automatically. |
You own backup, restore, and DR. MuleSoft provides control-plane availability and best practices. |
You design and run cross-region recovery. Not built in. |
You control the servers, which are managed through Anypoint Platform. |
On-Premises |
You cluster Mule runtime servers for automatic failover, using active-active, fault-tolerant, or zero-downtime topologies. |
You own the HA architecture, backup, restore, and DR for your servers and data. |
Not built in. You design and run cross-region recovery. |
On-premises clustering that you operate yourself. |
MuleSoft keeps the Anypoint Platform control plane resilient. In the managed runtime models, MuleSoft also keeps in-region infrastructure resilient; in self-managed and on-premises models, you own the infrastructure. In every model, you own any runtime strategy that spans regions.
| Cross-region DR in this matrix applies to Mule runtime regions only, not to the Anypoint Platform control plane. |
Best Practices
Follow these general design principles for high availability and disaster recovery:
-
Keep your integrations stateless.
-
Don’t share transactional information between client invocations or scheduled executions.
-
When the middleware must retain data because of a system limitation, persist it in an external store, such as a database or a messaging queue, rather than in the middleware infrastructure or memory.
-
As the system scales—especially in the cloud—keep each worker or node’s state and resources independent of the other workers, which delivers better performance, scalability, and reliability.