From 1c159c3f5248bf95f151292e84d181caa20f8278 Mon Sep 17 00:00:00 2001 From: ktroller Date: Mon, 13 Jul 2026 18:20:32 -0300 Subject: [PATCH 1/6] W-23431158: Link CloudHub HA/DR page to the HA/DR hub Add a pointer from the CloudHub High Availability and Disaster Recovery page to the Mule Runtime hub for a consistent cross-deployment experience. Co-authored-by: Cursor --- cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc index 1f4b6bbca..7c2bbd891 100644 --- a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc +++ b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc @@ -7,6 +7,8 @@ endif::[] CloudHub provides high availability (HA) and disaster recovery for application and hardware failures. +For an overview of HA and DR across all Mule deployment models, and to compare CloudHub with other options, see xref:mule-runtime::hadr-guide.adoc[High Availability and Disaster Recovery]. + CloudHub uses Amazon AWS for its cloud infrastructure, so availability depends on Amazon. CloudHub runs deployments in different regions that map to Amazon regions. If an Amazon region goes down, applications in that region become unavailable. CloudHub doesn't replicate them to other regions. For example, when the US East region is down, the CloudHub management UI and the REST services that enable deployments remain unavailable until the region recovers. You can't deploy new applications while US East is down. From e97089bdd2d6ff9d698543288f84e1f0856dd53c Mon Sep 17 00:00:00 2001 From: ktroller Date: Mon, 13 Jul 2026 18:44:59 -0300 Subject: [PATCH 2/6] W-23431158: Rewrite CloudHub HA/DR page to the shared skeleton with active voice Co-authored-by: Cursor --- .../modules/ROOT/pages/cloudhub-hadr.adoc | 109 +++++++++--------- 1 file changed, 57 insertions(+), 52 deletions(-) diff --git a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc index 7c2bbd891..c10fd34ab 100644 --- a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc +++ b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc @@ -4,103 +4,108 @@ include::_attributes.adoc[] endif::[] :page-aliases: runtime-manager::cloudhub-hadr.adoc - -CloudHub provides high availability (HA) and disaster recovery for application and hardware failures. +CloudHub provides high availability (HA) and disaster recovery (DR) that protect your applications from application and hardware failures. For an overview of HA and DR across all Mule deployment models, and to compare CloudHub with other options, see xref:mule-runtime::hadr-guide.adoc[High Availability and Disaster Recovery]. -CloudHub uses Amazon AWS for its cloud infrastructure, so availability depends on Amazon. CloudHub runs deployments in different regions that map to Amazon regions. If an Amazon region goes down, applications in that region become unavailable. CloudHub doesn't replicate them to other regions. - -For example, when the US East region is down, the CloudHub management UI and the REST services that enable deployments remain unavailable until the region recovers. You can't deploy new applications while US East is down. - -While the control plane is unavailable, the runtime plane continues to send log data and other telemetry data. The worker buffers up to 1 GB of data until the control plane recovers. - -CloudHub provides persistent queues for message reliability. Within a region, persistent queues are highly available, but when the region or part of it is down—usually for a few seconds or minutes—they become inaccessible and you sometimes lose data. When the region recovers, CloudHub resumes communication with the queues. - -Some CloudHub modules, such as Anypoint Object Store v1, application settings, and Insight-related information, reside in the US East region for all applications. Anypoint Object Store v2 resides in the same region as the deployed application. For both Object Store v1 and v2, when a region is down, data persists and becomes available again when the region returns to service. - -Anypoint Virtual Private Cloud (Anypoint VPC) applies at the region level. When a region is down, that region's VPC is down unless you've set up a VPC instance in another region. +CloudHub runs on Amazon AWS, so its availability depends on Amazon. CloudHub maps each deployment region to an Amazon region. If an Amazon region goes down, applications in that region become unavailable, and CloudHub does not replicate them to other regions. == High Availability Versus Disaster Recovery -High availability (HA) is the measure of a system's ability to remain accessible despite a system component failure. You generally implement HA by building multiple levels of fault tolerance or load balancing into a system. In CloudHub, you can achieve high availability by deploying your application with multiple workers and enabling persistent queues where appropriate. +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. On CloudHub, you achieve HA by deploying your application with multiple workers and by enabling persistent queues where appropriate. -Disaster recovery (DR) refers to the process of restoring a system to an acceptable previous state after a natural or man-made disaster, such as flooding, fires, power failures, server failures, or misconfigurations. +Disaster recovery (DR) restores a system to an acceptable previous state after a natural or man-made disaster, such as flooding, fires, power failures, server failures, or misconfigurations. -Both HA and DR increase availability, but with HA you typically see no loss of service. HA keeps the service up, DR preserves data. With DR, you usually see a brief loss of service while the DR plan runs and the system restores. +Both strategies increase availability, but they differ in one key way: HA generally keeps the service up 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. -These terms help you plan HA and DR on CloudHub: +Two measurable objectives drive your DR plan: Recovery Time Objective (RTO):: The maximum downtime a business tolerates. RTO is the time the system takes to recover after a disruption. -Recovery Point Objective (RPO):: The maximum acceptable data loss after a disaster. RPO drives how often you back up data. +Recovery Point Objective (RPO):: The maximum data loss a business accepts after a disaster. RPO drives how often you back up data. + +== High Availability in CloudHub -== Anypoint CloudHub Default Deployment Model +CloudHub builds high availability into its default deployment model, and MuleSoft manages it for you. -If the application uses multiple workers, CloudHub deploys the workers in separate availability zones by default, providing HA across availability zones. The distance between the availability zones is variable and generally doesn't exceed 350 miles. +When your application uses multiple workers, CloudHub deploys the workers in separate availability zones by default, which provides HA across availability zones. The distance between availability zones varies and generally stays under 350 miles. image::hadr-am-web-services.png[] -If an application uses a single worker and that availability zone goes down, CloudHub restarts the application in a different availability zone. The application can experience downtime during the restart. +When your application uses a single worker and that availability zone goes down, CloudHub restarts the application in a different availability zone. The application can experience downtime during the restart. -You can set up `status.mulesoft.com` to receive alerts when a failure occurs in an availability zone or region. +To receive alerts when a failure occurs in an availability zone or region, set up `status.mulesoft.com`. -== Shared Responsibility for Disaster Recovery +== Disaster Recovery in CloudHub -MuleSoft manages CloudHub control plane and worker infrastructure within each region. You're responsible for cross-region strategy, application-level failover, and data synchronization. This table lists who does what for disaster recovery on CloudHub. +MuleSoft manages the CloudHub control plane and worker infrastructure within each region. You own the cross-region strategy, application-level failover, and data synchronization. The following table shows who does what for disaster recovery on CloudHub. [%header,cols="1a,2a"] |=== |Party |Responsibility -|MuleSoft |Control plane availability: Anypoint Platform UI, deployment APIs, and platform services within the provisioned region. -|MuleSoft |Infrastructure patching, security updates, and maintenance of the worker cloud. -|MuleSoft |Multi-AZ worker distribution: when you use multiple workers, CloudHub deploys them across two or more availability zones within the same region. -|MuleSoft |Automatic restart of applications in a different availability zone when one worker or AZ fails. -|You |Define and implement a cross-region DR strategy for primary and backup regions. -|You |Decide when to trigger regional failover—for example, based on health checks or business criteria. -|You |Configure Global Server Load Balancing (GSLB) or a dedicated load balancer (DLB) and routing rules to direct traffic to a backup region during a disaster. -|You |Implement application-level failover strategy: deploy and maintain applications in more than one region when you need cross-region DR. -|You |Replicate and back up external data stores such as databases, object stores, and other systems that your applications use across regions. -|You |Set up Anypoint VPC in each region when you need network connectivity there for DR. +|MuleSoft |Keeps the control plane available, including the Anypoint Platform UI, deployment APIs, and platform services within the provisioned region. +|MuleSoft |Patches infrastructure, applies security updates, and maintains the worker cloud. +|MuleSoft |Distributes workers across two or more availability zones within the same region when you use multiple workers. +|MuleSoft |Restarts applications automatically in a different availability zone when a worker or availability zone fails. +|You |Define and implement a cross-region DR strategy for your primary and backup regions. +|You |Decide when to trigger a regional failover, for example, based on health checks or business criteria. +|You |Configure Global Server Load Balancing (GSLB) or a Dedicated Load Balancer (DLB), and set routing rules that direct traffic to a backup region during a disaster. +|You |Deploy and maintain applications in more than one region when you need cross-region DR. +|You |Replicate and back up the external data stores that your applications use across regions, such as databases and object stores. +|You |Set up Anypoint VPC in each region where you need network connectivity for DR. |=== === Your Responsibilities for Disaster Recovery -If your organization needs cross-region DR, design and operate your applications for it. MuleSoft doesn't automatically replicate applications or fail over traffic to another region. You're responsible for: +If your organization needs cross-region DR, design and operate your applications for it. MuleSoft does not automatically replicate applications or fail over traffic to another region. You own the following areas: -* Regional failover strategy: Decide when to switch traffic to a backup region—for example, after a region outage or based on health checks. -* Traffic management: Use a load balancer, cloud-based or on-premises, such as a Dedicated Load Balancer (DLB) or external GSLB, to route traffic to applications in different regions and to switch to the backup region as part of your DR plan. -* Application deployment: Deploy the same or equivalent applications in a backup region and keep them in sync with configuration and code. -* Data and state: Replicate or back up external data stores such as databases, caches, and object stores that your integrations use so applications in a DR region can access the data they need. Anypoint Object Store v1 and v2 are regional; they don't provide cross-region failover. +* *Regional failover strategy* - Decide when to switch traffic to a backup region, for example, after a region outage or based on health checks. +* *Traffic management* - Route traffic across regions with a cloud-based or on-premises load balancer, such as a Dedicated Load Balancer (DLB) or an external GSLB, and switch to the backup region as part of your DR plan. +* *Application deployment* - Deploy the same or equivalent applications in a backup region, and keep their configuration and code in sync. +* *Data and state* - Replicate or back up the external data stores that your integrations use, such as databases, caches, and object stores, so that applications in a DR region access the data they need. Anypoint Object Store v1 and v2 are regional and do not provide cross-region failover. For guidance on designing HA and DR topologies, including active-active, warm standby, and cold standby, see xref:mule-runtime::hadr-guide.adoc[High Availability and Disaster Recovery]. === Restoring After a Disaster -Restoration depends on the DR strategy you put in place. In general, after you confirm the primary region or application is unavailable: +Your restoration steps depend on the DR strategy you put in place. After you confirm that the primary region or application is unavailable, generally follow these steps: -. Switch traffic to the backup region. +. Switch traffic to the backup region. + -Use your load balancer, such as a GSLB or Dedicated Load Balancer (DLB), to route traffic to the backup region. The health checks you configured earlier mark the primary as unhealthy and direct traffic to the backup endpoints. If you use cold or warm standby, bring your backup applications online. -. Bring backup applications online when you use cold or warm standby. +Use your load balancer, such as a GSLB or a Dedicated Load Balancer (DLB), to route traffic to the backup region. The health checks you configured earlier mark the primary as unhealthy and direct traffic to the backup endpoints. +. Bring backup applications online when you use cold or warm standby. + -If the control plane is available, use Anypoint Runtime Manager or the CloudHub API to start the backup application or scale it up. If the control plane is in the same region as the failed primary, it is unavailable. You can't start or scale apps until the control plane recovers, unless you use automation that doesn't depend on the control plane. -. Verify that the backup region is serving traffic and that dependent systems use the correct endpoints or data stores. -. When the primary region recovers, optionally fail back by switching traffic from the backup region back to the primary and resyncing data when needed. +If the control plane is available, use Anypoint Runtime Manager or the CloudHub API to start or scale up the backup application. If the control plane sits in the same region as the failed primary, it is unavailable, and you cannot start or scale applications until the control plane recovers, unless you use automation that does not depend on the control plane. +. Verify that the backup region serves traffic and that dependent systems use the correct endpoints and data stores. +. Fail back when the primary region recovers, switching traffic from the backup region to the primary and resyncing data as needed. + +Your RTO depends on how quickly you complete these steps and, for cold or warm standby, on how long the backup application takes to start or scale. For active-active setups, traffic continues on the remaining region without a switch. For more on recovery types and topologies, see xref:mule-runtime::hadr-guide.adoc[] and xref:cloudhub-2::ch2-ha-dr.adoc[]. + +== Considerations and Limitations + +Account for the following CloudHub behaviors when you plan HA and DR: + +Control plane availability:: When the US East region goes down, the CloudHub management UI and the REST services that enable deployments stay unavailable until the region recovers, and you cannot deploy new applications during that time. + +Log and telemetry buffering:: While the control plane is unavailable, the runtime plane keeps sending log and telemetry data, and the worker buffers up to 1 GB of data until the control plane recovers. + +Persistent queues:: Within a region, persistent queues stay highly available. When the region or part of it goes down—usually for seconds or minutes—the queues become inaccessible and you can lose some data. CloudHub resumes communication with the queues after the region recovers. + +Object stores:: Anypoint Object Store v1, application settings, and Insight-related information reside in the US East region for all applications, and Anypoint Object Store v2 resides in the same region as the deployed application. For both versions, data persists during a region outage and becomes available again when the region returns to service. Neither version provides cross-region failover. -Your RTO depends on how quickly you complete these steps and, for cold or warm standby, on how long it takes to start or scale the backup application. For active-active setups, traffic continues on the remaining region without a switch. For more on recovery types and topologies, see xref:mule-runtime::hadr-guide.adoc[] and xref:cloudhub-2::ch2-ha-dr.adoc[]. +Anypoint VPC:: Anypoint Virtual Private Cloud (Anypoint VPC) applies at the region level. When a region goes down, that region's VPC goes down unless you set up a VPC instance in another region. -== Suggested Alternative Deployment Model +=== Suggested Alternative Deployment Model -You can use a cloud-based or on-premises load balancer for applications deployed to different regions to improve your disaster recovery strategy. Configure your load balancer to perform health checks and to route traffic to your backup region when the primary region goes down. For CloudHub-specific load balancing options, see xref:dedicated-load-balancer-tutorial.adoc[CloudHub Load Balancers] and xref:cloudhub-dedicated-load-balancer.adoc[Dedicated Load Balancers]. +To strengthen your DR strategy, route traffic across regions with a cloud-based or on-premises load balancer. Configure the load balancer to run health checks and to route traffic to your backup region when the primary region goes down. For CloudHub-specific options, see xref:dedicated-load-balancer-tutorial.adoc[CloudHub Load Balancers] and xref:cloudhub-dedicated-load-balancer.adoc[Dedicated Load Balancers]. image::hadr-load-balancer.png[] -== Keep Integrations Stateless +== Best Practices -Keep integrations stateless. Don't share transactional information between client invocations or scheduled runs. When the middleware needs to keep data because of a system limitation, store it in an external store such as a database or messaging queue, not in the middleware infrastructure or memory. +Keep your integrations stateless. Do not share transactional information between client invocations or scheduled runs. When the middleware must retain data because of a system limitation, store it in an external store, such as a database or a messaging queue, rather than in the middleware infrastructure or memory. -As you scale, especially in the cloud, keep each worker's state and resources independent of other workers. This model gives you better performance, scalability, and reliability. +As you scale, especially in the cloud, keep each worker's state and resources independent of the other workers. This model delivers better performance, scalability, and reliability. == See Also From 4eb12b9758be7126442409404b5be8a7a88405c5 Mon Sep 17 00:00:00 2001 From: ktroller Date: Mon, 13 Jul 2026 18:51:47 -0300 Subject: [PATCH 3/6] W-23431158: Optimize CloudHub HA/DR page for AI retrieval (alt text, table recap, distinct lead) Co-authored-by: Cursor --- cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc index c10fd34ab..4332ca40f 100644 --- a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc +++ b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc @@ -16,7 +16,7 @@ High availability (HA) measures a system's ability to remain accessible when a c Disaster recovery (DR) restores a system to an acceptable previous state after a natural or man-made disaster, such as flooding, fires, power failures, server failures, or misconfigurations. -Both strategies increase availability, but they differ in one key way: HA generally keeps the service up 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. +Both strategies increase availability but differ in scope: on CloudHub, HA keeps your application serving requests through worker and availability-zone failures with no loss of service, whereas DR restores service and data after a region-level disruption and usually incurs a brief loss of service while the DR plan runs. Two measurable objectives drive your DR plan: @@ -30,7 +30,7 @@ CloudHub builds high availability into its default deployment model, and MuleSof When your application uses multiple workers, CloudHub deploys the workers in separate availability zones by default, which provides HA across availability zones. The distance between availability zones varies and generally stays under 350 miles. -image::hadr-am-web-services.png[] +image::hadr-am-web-services.png["CloudHub deploying an application's workers across separate availability zones within a single region"] When your application uses a single worker and that availability zone goes down, CloudHub restarts the application in a different availability zone. The application can experience downtime during the restart. @@ -55,6 +55,8 @@ MuleSoft manages the CloudHub control plane and worker infrastructure within eac |You |Set up Anypoint VPC in each region where you need network connectivity for DR. |=== +In short, MuleSoft keeps the platform and workers resilient within a region, and you own everything that spans regions: when to fail over, how to route traffic, which applications to run in a backup region, and how to replicate data. + === Your Responsibilities for Disaster Recovery If your organization needs cross-region DR, design and operate your applications for it. MuleSoft does not automatically replicate applications or fail over traffic to another region. You own the following areas: @@ -99,7 +101,7 @@ Anypoint VPC:: Anypoint Virtual Private Cloud (Anypoint VPC) applies at the regi To strengthen your DR strategy, route traffic across regions with a cloud-based or on-premises load balancer. Configure the load balancer to run health checks and to route traffic to your backup region when the primary region goes down. For CloudHub-specific options, see xref:dedicated-load-balancer-tutorial.adoc[CloudHub Load Balancers] and xref:cloudhub-dedicated-load-balancer.adoc[Dedicated Load Balancers]. -image::hadr-load-balancer.png[] +image::hadr-load-balancer.png["A load balancer running health checks and routing traffic to a backup region when the primary region goes down"] == Best Practices From 1d40bae53aee96cf601c23e13f54ab022e66699d Mon Sep 17 00:00:00 2001 From: ktroller Date: Mon, 13 Jul 2026 19:05:48 -0300 Subject: [PATCH 4/6] W-23431158: Use contractions and remove 'the following' in CloudHub HA/DR page Co-authored-by: Cursor --- cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc index 4332ca40f..68f8a6fbd 100644 --- a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc +++ b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc @@ -8,7 +8,7 @@ CloudHub provides high availability (HA) and disaster recovery (DR) that protect For an overview of HA and DR across all Mule deployment models, and to compare CloudHub with other options, see xref:mule-runtime::hadr-guide.adoc[High Availability and Disaster Recovery]. -CloudHub runs on Amazon AWS, so its availability depends on Amazon. CloudHub maps each deployment region to an Amazon region. If an Amazon region goes down, applications in that region become unavailable, and CloudHub does not replicate them to other regions. +CloudHub runs on Amazon AWS, so its availability depends on Amazon. CloudHub maps each deployment region to an Amazon region. If an Amazon region goes down, applications in that region become unavailable, and CloudHub doesn't replicate them to other regions. == High Availability Versus Disaster Recovery @@ -38,7 +38,7 @@ To receive alerts when a failure occurs in an availability zone or region, set u == Disaster Recovery in CloudHub -MuleSoft manages the CloudHub control plane and worker infrastructure within each region. You own the cross-region strategy, application-level failover, and data synchronization. The following table shows who does what for disaster recovery on CloudHub. +MuleSoft manages the CloudHub control plane and worker infrastructure within each region. You own the cross-region strategy, application-level failover, and data synchronization. This table shows who does what for disaster recovery on CloudHub. [%header,cols="1a,2a"] |=== @@ -59,12 +59,12 @@ In short, MuleSoft keeps the platform and workers resilient within a region, and === Your Responsibilities for Disaster Recovery -If your organization needs cross-region DR, design and operate your applications for it. MuleSoft does not automatically replicate applications or fail over traffic to another region. You own the following areas: +If your organization needs cross-region DR, design and operate your applications for it. MuleSoft doesn't automatically replicate applications or fail over traffic to another region. You own these areas: * *Regional failover strategy* - Decide when to switch traffic to a backup region, for example, after a region outage or based on health checks. * *Traffic management* - Route traffic across regions with a cloud-based or on-premises load balancer, such as a Dedicated Load Balancer (DLB) or an external GSLB, and switch to the backup region as part of your DR plan. * *Application deployment* - Deploy the same or equivalent applications in a backup region, and keep their configuration and code in sync. -* *Data and state* - Replicate or back up the external data stores that your integrations use, such as databases, caches, and object stores, so that applications in a DR region access the data they need. Anypoint Object Store v1 and v2 are regional and do not provide cross-region failover. +* *Data and state* - Replicate or back up the external data stores that your integrations use, such as databases, caches, and object stores, so that applications in a DR region access the data they need. Anypoint Object Store v1 and v2 are regional and don't provide cross-region failover. For guidance on designing HA and DR topologies, including active-active, warm standby, and cold standby, see xref:mule-runtime::hadr-guide.adoc[High Availability and Disaster Recovery]. @@ -77,7 +77,7 @@ Your restoration steps depend on the DR strategy you put in place. After you con Use your load balancer, such as a GSLB or a Dedicated Load Balancer (DLB), to route traffic to the backup region. The health checks you configured earlier mark the primary as unhealthy and direct traffic to the backup endpoints. . Bring backup applications online when you use cold or warm standby. + -If the control plane is available, use Anypoint Runtime Manager or the CloudHub API to start or scale up the backup application. If the control plane sits in the same region as the failed primary, it is unavailable, and you cannot start or scale applications until the control plane recovers, unless you use automation that does not depend on the control plane. +If the control plane is available, use Anypoint Runtime Manager or the CloudHub API to start or scale up the backup application. If the control plane sits in the same region as the failed primary, it is unavailable, and you cannot start or scale applications until the control plane recovers, unless you use automation that doesn't depend on the control plane. . Verify that the backup region serves traffic and that dependent systems use the correct endpoints and data stores. . Fail back when the primary region recovers, switching traffic from the backup region to the primary and resyncing data as needed. @@ -85,7 +85,7 @@ Your RTO depends on how quickly you complete these steps and, for cold or warm s == Considerations and Limitations -Account for the following CloudHub behaviors when you plan HA and DR: +Account for these CloudHub behaviors when you plan HA and DR: Control plane availability:: When the US East region goes down, the CloudHub management UI and the REST services that enable deployments stay unavailable until the region recovers, and you cannot deploy new applications during that time. @@ -105,7 +105,7 @@ image::hadr-load-balancer.png["A load balancer running health checks and routing == Best Practices -Keep your integrations stateless. Do not share transactional information between client invocations or scheduled runs. When the middleware must retain data because of a system limitation, store it in an external store, such as a database or a messaging queue, rather than in the middleware infrastructure or memory. +Keep your integrations stateless. Don't share transactional information between client invocations or scheduled runs. When the middleware must retain data because of a system limitation, store it in an external store, such as a database or a messaging queue, rather than in the middleware infrastructure or memory. As you scale, especially in the cloud, keep each worker's state and resources independent of the other workers. This model delivers better performance, scalability, and reliability. From d3c2e1fa62ceec4036ea32dae937f14231ae7aa5 Mon Sep 17 00:00:00 2001 From: ktroller Date: Mon, 13 Jul 2026 20:09:03 -0300 Subject: [PATCH 5/6] W-23431158: Use bulleted Best Practices in CloudHub HA/DR page Co-authored-by: Cursor --- cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc index 68f8a6fbd..7fdab358a 100644 --- a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc +++ b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc @@ -105,9 +105,10 @@ image::hadr-load-balancer.png["A load balancer running health checks and routing == Best Practices -Keep your integrations stateless. Don't share transactional information between client invocations or scheduled runs. When the middleware must retain data because of a system limitation, store it in an external store, such as a database or a messaging queue, rather than in the middleware infrastructure or memory. - -As you scale, especially in the cloud, keep each worker's state and resources independent of the other workers. This model delivers better performance, scalability, and reliability. +* Keep your integrations stateless. +* Don't share transactional information between client invocations or scheduled runs. +* When the middleware must retain data because of a system limitation, store it in an external store, such as a database or a messaging queue, rather than in the middleware infrastructure or memory. +* As you scale, especially in the cloud, keep each worker's state and resources independent of the other workers, which delivers better performance, scalability, and reliability. == See Also From 06c6d3f36f9abeb6e5de9780d6862e8a1aa0f5c6 Mon Sep 17 00:00:00 2001 From: ktroller Date: Mon, 13 Jul 2026 20:45:45 -0300 Subject: [PATCH 6/6] W-23431158: Remove self-referential table lead from CloudHub HA/DR page Co-authored-by: Cursor --- cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc index 7fdab358a..c21e5cd52 100644 --- a/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc +++ b/cloudhub/modules/ROOT/pages/cloudhub-hadr.adoc @@ -38,7 +38,7 @@ To receive alerts when a failure occurs in an availability zone or region, set u == Disaster Recovery in CloudHub -MuleSoft manages the CloudHub control plane and worker infrastructure within each region. You own the cross-region strategy, application-level failover, and data synchronization. This table shows who does what for disaster recovery on CloudHub. +MuleSoft manages the CloudHub control plane and worker infrastructure within each region. You own the cross-region strategy, application-level failover, and data synchronization. Disaster recovery responsibilities on CloudHub divide between MuleSoft and you: [%header,cols="1a,2a"] |===