Introduction to Camunda 8

Introduction

This is the first article on Camunda in Practice, and it's deliberately just an introduction: what is Camunda 8, actually? Not the marketing answer — the one that helps you decide whether it belongs in your architecture, and gives you the vocabulary the rest of this publication will keep reusing.

It's also the exception, in a sense. The point of Camunda in Practice isn't to restate concepts you can already get from the documentation — it's to show Camunda 8 in practice: real processes, modeled and deployed, real workers, real trade-offs, the kind of detail that only shows up once something is actually running. This article lays the groundwork; the ones that follow will spend most of their time in that territory.

What is Camunda 8?

Camunda 8 is a platform for orchestrating processes that span people, systems, and — increasingly — AI agents. Instead of hand-rolling the coordination logic that decides "what happens next" across a set of services, you model that logic explicitly as a process and let an engine execute it, track its state, and recover it if something fails.

You can run it two ways: as a fully managed cloud offering, or as a Self-Managed deployment on your own infrastructure, typically on Kubernetes. The two share the same engine and APIs; they differ in who operates the cluster.

The Orchestration Cluster

At the center of a Camunda 8 deployment sits the Orchestration Cluster — the distributed system that actually runs your processes. Two ideas make it click.

First, the cluster keeps two different kinds of storage, and it's worth understanding why. Primary storage is the authoritative record of what a process is doing right now: partitioned logs and snapshots that the engine — Zeebe — writes to and replays from in order to recover after a crash. It's optimized for correctness and throughput, not for querying. Secondary storage is a separate store — Elasticsearch, OpenSearch, or a relational database, depending on how you deploy — populated asynchronously from primary storage specifically so that monitoring and analytics tools have something efficient to query without touching the hot path.

Second, that split is why the cluster can stay horizontally scalable and highly available while still giving you a full audit trail: the primary log is append-only, replicated across brokers using Raft consensus, and everything downstream is a projection of it.

Scroll horizontally to see the full diagram →

The Components You'll Actually Touch

"Camunda 8" is really a small constellation of components sitting around that cluster. The ones you'll run into first:

• Zeebe — the workflow and decision engine itself. Event-streaming based rather than built on a traditional database, which is what gives it horizontal scalability.
• Modeler — the design tool, desktop or web, where you draw and configure BPMN and DMN models that are directly executable, not just documentation.
• Job Workers & Connectors — the pieces that run outside the engine and do the actual work: calling an API, sending an email, invoking an AI agent. More on how they actually talk to the cluster below.
• Operate — the operational window into running and completed process instances: state, variables, and incidents, backed by secondary storage.
• Tasklist — the interface for human tasks, for the parts of a process that still need a person to make a decision.
• Optimize — analytics over historical execution data, for spotting bottlenecks rather than debugging a single instance.
• Console — cluster and user management, mostly relevant once you're operating more than one environment.

Job Workers

A job worker is the piece that runs outside the Orchestration Cluster and does whatever the process actually needs done: charge a card, call a legacy system, send an email. The cluster never calls the worker directly — it's the other way around. A worker polls Zeebe for jobs of a specific jobType, and for each one it gets handed, it eventually reports back one of two things: complete, with any resulting variables, or fail, with how many retries are left. That request/response cycle is the entire contract — Zeebe doesn't know or care what happens inside the worker, only whether the job came back completed or failed.

This is also what makes horizontal scaling straightforward on the worker side: run three instances of the same worker polling for charge-payment, and Zeebe hands each job to exactly one of them, without any coordination between the workers themselves.

Connectors are the same mechanism wearing a different hat: instead of writing the worker yourself, you configure a pre-built one — for a common API, a queue, an AI model — from inside the Modeler.

BPMN as the Executable Model

Every process is defined as a BPMN 2.0 diagram — the same open standard used for documentation-only flowcharts elsewhere, except here the diagram is the implementation. A start event, a handful of tasks, a gateway, an end event: that shape is enough to be deployed and run.

Take the same order process from above: validate the order, branch on whether it's valid, then either charge the payment or reject it. Each task carries the jobType a worker polls for — validate-order, charge-payment, reject-order — which is the whole connection between the model and the code that runs it. Here it is, open in Camunda Modeler:

And here's what it looks like once it's actually deployed and running, watched through Operate — one instance sitting at Validate Order, with its real process variables on the right:

This matters architecturally more than it sounds like it should: the model your business stakeholders review is the same artifact that executes in production. There's no translation step where intent gets lost.

Why Teams Reach for This

In practice, Camunda 8 tends to show up in a few recurring situations: coordinating a handful of microservices that need to agree on the state of a longer-running business transaction, replacing a tangle of if-this-then-that logic buried in application code with something visible and auditable, or stitching human approval steps into an otherwise automated flow. More recently, the same mechanism — a governed, auditable process definition — is being used to keep AI agents on a leash: the model decides what to do, the process still decides whether it's allowed to.

Conclusion

Camunda 8 is, at its core, a distributed engine for running BPMN processes reliably, plus a set of components built around it for modeling, operating, and observing that execution. The split between primary and secondary storage is the detail that explains most of the rest of the architecture — keep it in mind, it comes up again.

References