Zeebe Scaled Workflow Orchestration Horizontally. Governance Did Not Scale With It.

Vendor and Product Reality

Camunda built Zeebe specifically to overcome the throughput limits of its earlier relational-database-backed engine. Zeebe partitions process state across brokers in a Raft-replicated cluster. Each partition is a self-contained log; each broker owns a subset of partitions; clients submit commands through a gRPC gateway and the gateway routes them to the partition that owns the relevant process instance. Job workers — external processes that perform service tasks — poll for activated jobs and report completion back through the same gateway. Exporters stream the event log to downstream systems for monitoring, audit, and analytics.

The result is a workflow engine that handles millions of concurrent process instances with predictable latency. BPMN models are deployed once and execute many times. The engine's internal logic — token movement, gateway evaluation, timer firing, message correlation — is encoded in the broker. Customers like banks, telcos, and large-scale order-management platforms run Zeebe because the throughput envelope and the operational characteristics match the workload. The technical execution at the orchestration layer is mature. There is no claim here that Zeebe fails at what it sets out to do.

The architectural question is where the rules that govern each running instance live, and what travels with the instance when it moves through the system.

Architectural Gap: Authority Is Broker-Side

In Zeebe, a process instance is a token position plus a payload of process variables. The rules that govern that instance — which sequence flows are valid, which conditions gate which gateways, which job types are dispatched to which workers, which authorization context applies to which task — are encoded in the BPMN model deployed to the broker and in the configuration of the gateway, the workers, and the exporters. The instance carries the variables. The broker carries the rules. When a step executes, the broker consults its deployed model and its configuration, decides what is allowed, and emits the corresponding events.

This is a clean separation for a pure orchestration engine. It is also the gap. Because rules are broker-side, scaling the broker scales execution throughput but does not scale the governance applied to each unit of throughput. Every partition runs the same deployed model with the same configured handlers. There is no mechanism for a process instance to carry its own scoped policy — its own authorization context, its own data-handling constraints, its own trust-slope requirements — and have that scoped policy enforced at each step regardless of which partition or which broker happens to be processing the instance at that moment.

The event stream compounds the gap. Zeebe's event sourcing records what happened: token moved here, job activated, job completed, variable updated. It does not record governance evaluation. There is no event that says "at this step, this policy was evaluated against these inputs and admitted the action." The audit log answers the question "what did the workflow do" but not the question "what authorization did each step act under." For workflows that orchestrate agent actions, cross-tenant data flows, or regulated operations, the absence of governance events means the audit log is structurally incomplete: it captures execution but not authority.

As throughput rises — more instances, more partitions, more brokers — the proportion of execution covered by structurally-recorded governance does not rise with it. Governance becomes proportionally less present as throughput increases, because governance is a property of the broker's configuration, not a property of the instance. More workflows execute. Each workflow receives the same broker-side policy, and each workflow leaves the same governance-free trace.

What the Execution-Platform Primitive Provides

The execution-platform primitive inverts the locus of authority. Rules are not attached to the broker; they ride with the data. A process instance carries, in addition to its variables, a credentialed policy structure that scopes what the instance is permitted to do. At each step, the executor — whether broker, worker, or sidecar — admits the candidate action against the instance-resident policy. The admission produces a governance event that becomes part of the same event log as the execution events. The audit log records both what happened and the authority under which it happened.

Because the policy travels with the instance, governance scales with throughput by construction. Doubling the partition count doubles both the execution capacity and the governance applied to each unit of execution. Heterogeneous policy — instance-specific authorization context, tenant-specific data constraints, workflow-specific trust requirements — becomes natural rather than awkward. The broker no longer needs to be the canonical source of governance; it can be a participant in evaluating policy that the instance itself carries.

Trust-slope validation, in particular, becomes a partitioned operation. The slope from the workflow's initiator to the current actuator is recorded in the instance's policy structure and re-evaluated at each step. A step that would extend the slope beyond what the policy admits is rejected before it executes. The rejection is itself a governance event in the log.

Composition Pathway With Zeebe

The integration with Zeebe is staged. The first stage attaches the credentialed policy structure to the process instance as a reserved variable, and inserts an admissibility evaluator into the job-worker dispatch path. Workers receive both the job payload and the policy structure; the worker admits the job against the policy before executing; the admission emits a governance event through a Zeebe exporter. Existing BPMN models continue to deploy unchanged; existing workers continue to function; the policy is additive.

The second stage moves the evaluator inside the broker, so that gateway evaluation and sequence-flow decisions also pass through the policy. Zeebe's exporter mechanism becomes the natural channel for governance events; the same downstream systems that consume execution events consume governance events alongside them, and audit, monitoring, and analytics gain governance visibility without a separate pipeline.

The third stage propagates the policy structure across workflow boundaries. A subprocess inherits the parent's policy; a message-correlated start event admits against the originating instance's policy; a workflow that calls another workflow propagates a scoped derivative of its own authority rather than relying on broker-side configuration to determine what the called workflow may do. The result is an execution platform where authority is a property of the data flowing through the system, not a property of the system the data flows through.

Commercial and Licensing Posture

Camunda's commercial position with Zeebe is strongest in regulated industries — banking, insurance, telco — where workflow throughput and operational maturity are non-negotiable and where audit obligations are heavy. These are the same industries where the broker-side-authority gap is most exposed: regulators are increasingly asking not only what a workflow did but under what authorization each step acted, and the answer "the deployed BPMN model permitted it" is becoming insufficient. Workflows that orchestrate AI-agent actions, cross-tenant data flows, or counterparty-sensitive operations will face this question first.

Adopting the execution-platform primitive as the data-side authority layer above Zeebe converts that exposure into a differentiator. Zeebe's throughput remains the throughput story; the addition is that every unit of throughput carries its own credentialed policy and emits its own governance event. The patent is positioned at the layer that the regulatory trajectory targets — the layer where authority lives — and the additive integration model means existing Zeebe deployments can absorb the primitive without re-architecting the broker. Licensing terms contemplate per-cluster and per-throughput structures appropriate to enterprise workflow procurement, and the composition pathway preserves Camunda's existing commercial relationships with the customers most exposed to the governance question. Workers, exporters, gateway clients, and BPMN models continue to function unchanged; the addition is that each instance carries its own credentialed scope and emits its own governance trace, so the answer to "under what authority did this step act" stops being a function of broker configuration and becomes a property of the workflow data itself.