Microservices orchestration that holds up when things go wrong
End-to-end processes that complete, recover, and stay visible across every service you ship
Why microservices coordination matters to the business
A microservices architecture is an internal choice. The customer never sees the services. They see whether the order shipped, the policy issued, the refund posted. When coordination drifts across teams, that visibility breaks down in exactly the places the business cares about most: cycle time, customer experience, and the audit trail behind every operational decision.
Key takeaways
- Coordination logic stops living in every team’s codebase and starts living in one auditable, visible process model.
- Customers see complete outcomes — not the partial failures that happen when services lose track of each other.
- When a transaction stalls, operations sees it immediately — without paging engineering or pulling logs from six services.
- In-flight instances survive restarts and releases; there are no maintenance windows for process model updates.
End-to-end visibility for operations
Operations and support need to answer “where is order #4523?” in seconds, not after escalating to engineering. Orchestration gives them the same view of every case in flight that developers see, so customer questions get real answers.
Reliability the customer can feel
A failure between charging the card and shipping the goods is worse than a duplicate charge. Built-in saga and compensation make sure every multi-step transaction either completes or rolls back cleanly, so customers don’t see partial outcomes.
Programs that finish on schedule
When coordination logic is everywhere and owned by no one, every new initiative inherits the previous teams’ workarounds. With one orchestration layer, programs ship on schedule because the integration plumbing is already solved.
How the distributed monolith happens
You went to microservices for the right reasons: independent deployment, team autonomy, scaling individual hot paths. Then payment-service called inventory-service called shipping-service, the second one timed out, and now coordination logic is everywhere and nowhere.
Coordination logic that’s everywhere and nowhere
A retry-with-backoff wrapper here. A saga compensator there. A state column in Postgres that drifts out of sync with reality. Every team has its own version, and none of them are your differentiator.
The business process lives in nobody’s repo
It’s spread across event logs, dashboards, and Slack threads. When something stops mid-flight, no one can answer “where is order #4523?” without pulling logs from six services.
Failure recovery that’s almost right
Your retry logic handles 80% of failure cases and silently breaks on the other 20%. Charging a card and not shipping the goods is a worse failure than charging twice, and your code knows it.
What is microservices orchestration?
Microservices orchestration is the coordination of multiple services into end-to-end business processes by a central engine that holds state, sequences calls, handles failure, and exposes the full process to operators. It is the alternative to pure choreography, where services react to events with no one owning the overall flow.
Camunda is the orchestration layer between your services. We give you a distributed orchestration engine, an open notation (BPMN) for expressing the flow, and the operational tooling you would otherwise build yourself. Your services stay focused on what they do well. The orchestration logic lives in one model, runs on one engine, and shows up in one place when something goes wrong.
One process model, every microservices coordination pattern
Zeebe, the orchestration engine inside Camunda, is distributed by design, has no central database, runs as peer-to-peer brokers, and is built for processes that take milliseconds or months. The patterns the microservices and AI communities have converged on (saga, durable execution, fan-out/join, dehydration) are first-class capabilities, not libraries you wire together yourself.
Saga and compensation
If step three fails, the engine runs compensating actions for steps two and one, in reverse order. Compensation logic lives in the diagram, not in catch blocks scattered across services.
Durable execution
Every state transition is written to a durable log. Process instances survive broker restarts, redeployments, and infrastructure failures, then pick up at the right step on the other side.
Event correlation
Processes pause for hours, days, or weeks waiting for a message, a callback, or a timer. Dehydrated instances cost zero memory and zero CPU until the next event arrives.
Versioning
Ship process v4 while v3 instances continue safely on the version they started. Migrate in-flight instances when you’re ready. No drained queues, no maintenance windows.
Fan-out and join
Run dozens of service calls in parallel under one process. The engine tracks completion, handles partial failures, and fires the join exactly once.
Timers and SLAs
Timeouts, escalations, and SLA boundaries live in the diagram. No separate scheduler, no cron, no out-of-band policy that drifts away from the code.
Audit replay
Complete, immutable history of which service was called, what it returned, and why a path was taken. Compliance gets a record that’s always in sync with what actually ran.
Operate
Camunda Operate shows every instance, every incident, every backlog. Bulk-retry stuck instances when you push the fix. No new dashboard to build.
Linear horizontal scale
Peer-to-peer broker cluster, no central database, no single point of failure. Throughput scales linearly by adding broker nodes.
BPMN + code, built on open standards
Design processes in code or in a visual modeler that compiles to standard BPMN XML. Implement the work itself in your services. Ship the process model alongside your code, version it, diff it, code-review it.
Camunda is built for developers who want the composability of open standards and the power of code. You stay in your stack. You commit BPMN to git. You wire connectors for SAP, Salesforce, ServiceNow, and any system reachable via REST, gRPC, MCP, or A2A. You deploy to your own Kubernetes or to Camunda’s SaaS.
- SDKs. Java, Go, Python, Node.js. Idiomatic clients with workers, retries, and serialization built in.
- Full REST API. Anything the platform does, your code can do. CI/CD friendly.
- BPMN XML in your repo. Versioned, reviewed, diffed like any other source artifact.
- Pre-built connectors. SAP, Salesforce, ServiceNow, Kafka, S3, plus a public marketplace.
- Local dev environment. Docker Compose, CLI, and “hello world” in 10 minutes.
- Free tier. Self-serve. No sales call required to evaluate.
When to orchestrate, and when not to
Choreography (services reacting to events without a central coordinator) works well for loosely-coupled fan-outs where order doesn’t matter, no single business outcome is at stake, and observability is mostly about service health. Orchestration earns its keep when the answer to any of these is yes:
| Question | If yes, orchestrate |
|---|---|
| Do you need to know the status of a business outcome, not just service health? | Operations needs to answer “where is order #4523?” without grepping six services. |
| Does failure recovery need to compensate, not just retry? | Charging a card and not shipping the goods is a worse failure than charging twice. |
| Does the flow run for hours, days, or weeks? | Long-running state, timers, signatures, and external callbacks need a durable home. |
| Does compliance need an audit trail of why a path was taken? | “Show me the decision history” is a tractable query, not a six-week project. |
| Are humans in the loop somewhere? | Approvals, exceptions, and overrides need first-class support, not a custom UI. |
Most enterprise systems mix both patterns. Camunda fits the orchestration parts. Your event bus (Kafka, NATS, RabbitMQ) handles the choreography parts. The orchestration engine consumes and publishes events natively, so you don’t have to choose architectures up front.
Microservices orchestration in production
Enterprises running Camunda as the coordination layer between their services.
Quick answers for evaluators
What is the difference between microservices orchestration and choreography?
Orchestration uses a central engine that holds the flow’s state, sequences service calls, and recovers from failure. Choreography has services react to events independently, with no one owning the overall outcome. Orchestration is the right fit when you need to know the status of a business process, compensate for partial failures, or run flows that span hours and days. Choreography works for loosely-coupled fan-outs. Most production systems mix both, and Camunda integrates with event buses like Kafka and NATS so you don’t have to choose up front.
Does Camunda require BPMN, or can I just use code?
Both. Author flows in Java, Go, Python, or Node.js using the SDKs, or design them in a visual modeler that exports the same BPMN XML. The orchestration model is a file in your repo, versioned and reviewed alongside the rest of your code.
How does Zeebe scale?
Linearly. Zeebe is a peer-to-peer broker cluster with no central database and no single point of failure. Add broker nodes to add throughput. Customers run it for processes that take milliseconds and processes that take months, in the same cluster.
Can Camunda handle short, high-throughput service calls and long-running business processes in the same model?
Yes. Dehydrated process instances cost zero memory and CPU until the next event arrives, so a long-running flow waiting on a human approval doesn’t compete with a millisecond-scale order routing flow. They run on the same engine.
What happens to in-flight instances when I deploy a new process version?
Existing instances keep running on the version they started. New instances pick up the new version. You can migrate in-flight instances explicitly when you’re ready. No drained queues, no maintenance windows, no big-bang releases.
Ready to get started?
See how Camunda turns coordination logic spread across every team into one durable, observable, end-to-end process.