When a region goes down, the question is what happens to the work in flight. Re-engineering processes around what AI can now do is the work of the next few years, and the limit on how far an enterprise takes it is rarely model quality or connector coverage. It is how much you can trust the platform underneath when a region fails.
The processes most worth re-engineering are usually the ones a business cannot stop running for even an afternoon: payments, claims adjudication, trade settlement, order fulfillment. Moving those onto an agentic orchestration platform is a decision about resilience as much as it is about capability.
Camunda 8.10 introduces zone-aware clusters RDBMS failover recovery, and two validated multi-region reference architectures for Self-Managed deployments. These additions help platform teams spread workloads across regions and recover secondary data after a database failover. Deployments can also be built around defined availability and data-loss requirements.
The change that matters most for your data-loss budget is how RDBMS failover recovery works. Because the engine can replay missing records into secondary storage from its own primary storage, a promoted database that was behind at failover no longer costs your process data, so you can achieve recovery point objective (RPO) of 0 for the entire Orchestration Cluster even when your relational database replicates asynchronously. Previously, that guarantee required synchronous replication, with the latency and cost that implies.
Alongside this, region-aware placement makes replica distribution explicit, and new Kubernetes and AWS ECS blueprints document how to configure and operate these capabilities across regions.
Region-aware partition placement
Resilience starts with where your data lives. Running brokers in multiple regions is only part of the design: partition replicas must also be distributed so the cluster can recover safely when a region becomes unavailable.
In Camunda 8.10, operators can assign a zone to each Zeebe Broker to identify its region, availability zone, or on-premises data center. The engine uses these labels to distribute partition replicas across the configured groups, reducing reliance on manual placement tuning as the cluster topology changes.
For an appropriately configured three-region deployment, this distribution allows the surviving regions to retain quorum (the majority of partition replicas required to continue processing safely) after the loss of a single region. Leadership follows a static per-zone priority.
This gives operators an explicit way to express their deployment topology and align replica placement with recovery requirements. It does not automatically redistribute replicas during a regional outage or route process instances to a preferred region.
Camunda 8.10 also adds APIs to change the zones configuration on the fly, which greatly simplifies the switchover/failover or failback procedures; for example, adding a zone back once a region recovers.
RDBMS failover recovery while the engine keeps running
Camunda 8.10 adds defined recovery behavior for global relational databases used as secondary storage. This covers both temporary database unavailability and record loss due to asynchronous replication of secondary storage during failover.
When the active database endpoint becomes unreachable, exporting pauses and resumes upon reconnection. If a promoted database is missing records (for example, because asynchronous replication had not caught up before failover), the engine recovers those records from its primary storage and restores the secondary database state.
The engine continues processing while secondary storage recovers. This separates process execution from database recovery, although applications and queries that depend on secondary storage may remain unavailable or show delayed data until recovery catches up.
Region C is in outage, and its broker is unreachable. Regions A and B still hold a majority of partition replicas, so processing continues without Region C.
For databases with native cross-region replication, such as Aurora Global Database, operators can configure exports to a single logical database endpoint instead of maintaining separate region-specific exporter configurations.
The capability applies across supported deployment models, giving teams a consistent recovery mechanism whether they run Camunda on Kubernetes, ECS, or another supported platform.
New multi-region reference architectures
To help teams put these capabilities into practice, Camunda 8.10 adds validated reference architectures for three-region (or more) Kubernetes and dual-region AWS ECS deployments. Each combines a recommended topology with configuration examples and operational guidance, providing a supported starting point for implementation and recovery testing.
Three-region Kubernetes
The new Kubernetes architecture combines a Zeebe stretch cluster across three regions with a multi-region global RDBMS for secondary storage. Zeebe, the process automation engine at the heart of Camunda, has no central coordinator. Brokers form a peer-to-peer cluster, and each partition fails over to another replica when its leader’s node goes down, as long as a majority of that partition’s replicas survive. This release extends that resilience across regions.
Region-aware placement distributes primary storage replicas so that the engine can maintain quorum after losing one region. Secondary storage uses synchronous or asynchronous replication, depending on the chosen database and recovery requirements.
The documentation includes architecture diagrams, sample Terraform and Kubernetes manifests, and runbooks for single-region loss, network partitions between regions, and RDBMS failures in a single region. It also explains how quorum behavior prevents split-brain.
For teams that must maintain engine availability during a regional outage, this blueprint provides a validated design and a repeatable basis for recovery exercises.
Dual-region AWS ECS
The new ECS/Fargate architecture runs the Orchestration Cluster and Connectors across two AWS regions, with Aurora Global Database providing secondary storage.
Dual-region AWS ECS deployment. Region A runs the primary Orchestration Cluster and Connectors. Aurora Global Database replicates between the two regions, and failover promotes the Region B endpoint, with a recovery time objective above zero.
The guide brings together the recommended topology, exporter configuration, VPC peering, and Transit Gateway networking options, along with step-by-step failover and failback procedures. Teams standardizing on ECS can use it to implement regional recovery without having to design and validate every component interaction from scratch.
The dual-region architecture preserves process data during regional recovery, with an RPO of 0. Recovery involves an outage, so its recovery time objective (RTO) remains greater than zero.
Choose the topology that matches your recovery requirements
The two architectures address different availability requirements. RPO describes acceptable data loss; RTO describes acceptable downtime.
Preserve process data, with an outage during recovery
Two regions support RPO = 0 with RTO > 0.
Maintain engine availability through regional loss
RTO = 0 requires at least three regions, with replica placement configured to preserve quorum.
These objectives describe engine recovery. End-to-end application availability also depends on secondary storage and the other services your processes use. Database replication and failover should therefore be tested alongside engine recovery as part of the same operational exercise.
Why this matters for the Great Process Re-Engineering
Camunda orchestrates agents from the outside, as participants in an end-to-end process, and from the inside, with enforceable steps between an agent's reasoning and its actions. Before an agent moves money, the process can require a policy check or a human approval.
Re-engineering a process around AI moves coordination work that people used to hold together onto the platform itself. Agents decide, systems act, and no team is manually shepherding the process when something breaks. The platform becomes load-bearing for business operations in a way that earlier automation tooling never was. Camunda blends deterministic steps, where the rules are fixed, with dynamic agent decisions, where judgment is needed.
That changes what you should ask of a platform before committing your highest-value processes to it. Not only what its agents can do, but what the platform underneath them does when a region fails mid-process: whether the process state survives, whether the engine keeps making progress, and whether recovery follows a documented procedure rather than an improvisation.
Region-aware placement, RDBMS failover recovery, and validated multi-region architectures are how Camunda answers that question. They are also why the list of processes an enterprise can responsibly re-engineer gets longer. Platform trust, rather than any single capability, decides how much ofthe Great Process Re-Engineering an organization actually captures.
Get started with Camunda 8.10
These capabilities and reference architectures are available with Camunda 8.10 Self-Managed. Existing deployments can evaluate topology labels and RDBMS recovery configuration as part of their upgrade; deployments without topology labels retain their existing placement behavior.
If you are extending a single-region deployment, start with the reference architecture for your platform and recovery requirements. If you already operate across regions, use the new guidance to review replica distribution, database failover, and recovery procedures against your current design.
Explore theMulti-Region Resilience Tiers to plan your deployment and validate recovery against your own workloads. Camunda is the enterprise platform for agentic orchestration.
