Como funciona o Zeebe por dentro? Entendendo o engine de processos do Camunda 8
- William Robert Alves
- 20 de jul.
- 3 min de leitura
Atualizado: 23 de jul.
Se você usa ou está começando com Camunda 8, provavelmente já ouviu falar no Zeebe, o motor de processos que dá vida aos seus workflows.
Mas... o que é exatamente o Zeebe?
E mais importante: como ele funciona por dentro?
Se você é do tipo que não se contenta em só "usar a ferramenta" e quer entender a engenharia por trás, esse artigo é pra você.
Aqui você vai descobrir:
Como o Zeebe executa BPMN em escala.
Como ele garante performance, resiliência e escalabilidade.
E como a arquitetura dele é diferente dos engines tradicionais, como o do Camunda 7.
O que é o Zeebe?
O Zeebe é o engine de workflow distribuído que alimenta o Camunda 8.
Diferente dos motores BPMN tradicionais, o Zeebe foi projetado para:
Alta escalabilidade.
Execução distribuída.
Resiliência nativa para cloud.
Performance consistente, mesmo com milhares ou milhões de instâncias rodando simultaneamente.
Ele não roda em banco relacional. Ele roda sobre logs distribuídos, um paradigma muito mais escalável.
Visão arquitetural do Zeebe
Zeebe é um Log-Based Workflow Engine.
Ele se inspira no modelo arquitetural do Kafka, do CockroachDB e de outros sistemas distribuídos modernos.
O log é a verdade absoluta.
Todos os eventos — criação de instância, execução de tarefa, conclusão de etapa — são gravados como entradas num log imutável.
Esse log é particionado e replicado, permitindo:
✔️ Failover automático.
✔️ Escalabilidade horizontal.
✔️ Processamento altamente paralelo.
Componentes internos do Zeebe
🔹 Brokers (Cluster nodes)
Cada broker gerencia uma ou mais partições do log.
🔹 Partitions (Shards)
Dividem a carga. Cada partição tem um líder e réplicas para tolerância a falhas.
🔹 Streams
Fluxos de eventos que representam tudo o que acontece no processo.
🔹 State machine
Cada partição mantém uma cópia do estado derivada do log, usando uma estrutura chamada RocksDB (banco de dados embutido de key-value).
🔹 Command/Response + Event sourcing
Toda operação no processo (start, complete, fail, retry) é um comando que gera um ou mais eventos persistidos no log.
Fluxo interno de execução
1️⃣ Você envia um comando (ex.: start instance).
2️⃣ O broker escreve no log da partição responsável.
3️⃣ Uma máquina de estados lê o log, aplica a transição, e atualiza o estado local (RocksDB).
4️⃣ Se necessário, ele dispara jobs (tarefas) para workers externos.
5️⃣ O job fica pendente até um worker buscá-lo, executá-lo e reportar o completion.
6️⃣ Tudo isso é gravado no log — garantindo consistência e rastreabilidade total.
Por que isso é revolucionário e diferenciado?
🚫 Sem banco relacional (SQL).
→ Isso elimina o maior gargalo dos engines tradicionais.
🏗️ Arquitetura cloud native de verdade.
→ Cada broker é stateless no sentido de que o estado vem do log e da persistência local (RocksDB).
🔄 Failover transparente.
→ Se um broker cai, outro assume a partição, sem perda de dados.
📈 Escalabilidade horizontal real.
→ Basta adicionar mais brokers e particionar os processos.
Mas e aí Will... Onde estão meus processos?
Os BPMN que você deploya são convertidos internamente em estruturas de dados que o Zeebe interpreta.
Cada token do BPMN (entrada, gateway, serviço, etc.) vira uma série de comandos e eventos no log.
✔️ Isso significa que seu processo não é um registro no banco.
✔️ Seu processo é um fluxo de eventos persistidos, reproduzíveis e auditáveis.
Como o Zeebe garante consistência?
Cada partição usa Raft Consensus Algorithm para garantir que leaders e followers estejam sincronizados.
Mesmo em caso de falha, o estado pode ser reconstruído 100% a partir do log.
Não existe ponto único de falha.
⚠️ Trade-offs importantes
✅ Ganha:
Escalabilidade massiva.
Failover automático.
Baixa latência em grandes volumes.
❌ Perde (em relação ao Camunda 7 ou motores SQL-based):
Não tem suporte a transações ACID multi-recurso.
Eventual consistency é normal no modelo distribuído.
Debug pode ser mais complexo para quem vem de mundo relacional.
Resumo visual da arquitetura do Zeebe
ZEEBE CLUSTER |
PARTITION 1 | PARTITION 2 | ... |
(Leader) | (Leader) | ... |
(Follower) | (Follower) | ... |
Cada partição contém:
Log de eventos;
Máquina de estados (RocksDB);
Command Handlers;
Event processors.
Workers:
Escutam jobs via gRPC;
Executam tarefas externas;
Reportam status.
O Zeebe não é só um "engine de processos"...
É uma infraestrutura distribuída de execução de processos, pensada para um mundo cloud-native, escalável e resiliente.
Se você entende Kafka, Event Sourcing e microservices, vai curtir muito a arquitetura do Zeebe.
Se não entende… bom, talvez esse seja o melhor motivo pra começar agora.
Site oficial da Camunda: https://camunda.com/
Conheça também o blog oficial: https://camunda.com/blog/
Quer conhecer um pouco mais sobre esta ferramenta e outras tecnologias?
Nos siga nas redes sociais @gerandocodigo (instagram / youtube / tiktok / facebook).
Comentários