Camunda 8 – Zeebe Broker expliqué pour les débutants

Guide simple pour comprendre comment Camunda 8 fonctionne vraiment

Introduction

Si vous débutez avec Camunda 8, un terme revient partout :

❓ Zeebe Broker

Mais qu’est-ce que c’est exactement ?

Est-ce une base de données ?
Un message broker ?
Le moteur BPM ?

👉 Réponse courte :
Le Zeebe Broker est le cœur de Camunda 8.

Dans ce blog, nous expliquons :

• Ce qu’est le Zeebe Broker

• Pourquoi il existe

• Comment il fonctionne en interne

• Comment il exécute le BPMN

• Comment il passe à l’échelle

• Ce que les débutants doivent absolument comprendre

---

Qu’est-ce que le Zeebe Broker ?

Le Zeebe Broker est le moteur de workflow distribué de Camunda 8.

Il est responsable de :

• L’exécution des workflows BPMN

• La persistance de l’état des processus

• La gestion des messages et des jobs

• La distribution du travail entre les nœuds

• La tolérance aux pannes

Contrairement à Camunda 7, Zeebe est :

• Événementiel (event-driven)

• Basé sur un log append-only

• Conçu pour fonctionner en cluster

👉 Pensez à Zeebe comme à une machine d’état BPMN construite sur un log distribué.

---

Zeebe n’est PAS une base de données ni une simple file de messages

Beaucoup de débutants se trompent sur Zeebe.

❌ Ce que Zeebe n’est pas

• ❌ Une base de données relationnelle

• ❌ Kafka

• ❌ RabbitMQ

• ❌ Une simple file de jobs

✅ Ce que Zeebe est réellement

• Un moteur de workflow distribué

• Un système de log append-only

• Un processeur de flux (stream processor)

• Une machine d’état BPMN

---

Architecture globale (vue simplifiée)

Composants principaux

Workflow BPMN
      ↓
Zeebe Broker
      ↓
Log distribué
      ↓
Stream Processor
      ↓
État (mémoire + RocksDB)

Autres services Camunda 8 :

• Operate – Supervision & debug

• Tasklist – Tâches humaines

• Optimize – Analytics

• Identity – Authentification

• Workers externes – Logique métier

---

Comment Zeebe exécute un workflow BPMN

Prenons un scénario simple.

Étapes

1. Le BPMN est déployé dans Zeebe

2. Une instance de workflow est démarrée

3. Zeebe écrit un événement dans le log

4. Les stream processors consomment l’événement

5. L’état interne est mis à jour

6. L’étape BPMN suivante est activée

7. Un job est créé pour un worker

8. Le worker exécute la logique

9. Le worker complète le job

10. Zeebe écrit un nouvel événement

Événement → Log → Traitement → État → Étape suivante → Événement

👉 Tout dans Zeebe est piloté par des événements.

---

Pourquoi Zeebe utilise un log append-only

C’est le concept le plus important.

Moteurs classiques (Camunda 7)

BPMN → Transaction DB → Commit → Étape suivante

Zeebe (Camunda 8)

BPMN → Événement → Ajout au log → Traitement → Mise à jour de l’état

Avantages

✔ Scalabilité horizontale
✔ Tolérance aux pannes
✔ État rejouable
✔ Très haut débit

Inconvénients

❌ Pas de rollback classique
❌ Cohérence éventuelle
❌ Nécessite des compensations

---

Qu’est-ce qu’une partition Zeebe ?

Une partition est une portion des données de workflow.

• Chaque partition a :

  • Un leader

  • Un ou plusieurs followers

• Le leader gère :

  • Les écritures

  • La création des jobs

• Les followers répliquent les données

Partition 1 → Broker A (Leader)
Partition 2 → Broker B (Leader)
Partition 3 → Broker C (Leader)

👉 Les partitions permettent à Zeebe de passer à l’échelle horizontalement.

---

Que se passe-t-il si un nœud broker tombe ?

Zeebe est hautement tolérant aux pannes.

Scénario de panne

1. Le Broker A s’arrête

2. Le leader de partition disparaît

3. Un follower devient leader

4. Le traitement continue

👉 Pas de perte de données
👉 Pas d’intervention manuelle

---

Comment fonctionnent les jobs et les workers

Zeebe n’exécute pas la logique métier.

À la place :

1. Le BPMN atteint une Service Task

2. Zeebe crée un job

3. Les workers externes récupèrent le job

4. Le worker exécute la logique

5. Le worker complète le job

6. Zeebe poursuit le workflow

BPMN → Job → Worker → Complete → Étape suivante

👉 Toute la logique est externalisée.

---

Pourquoi Zeebe est très différent de Camunda 7

Concept	Camunda 7	Camunda 8 (Zeebe)
Modèle d’exécution	Transactions DB	Événementiel
Stockage état	Base relationnelle	Log + store état
Rollback	Oui	Non (compensation)
Java Delegates	Oui	Non
External Tasks	Optionnels	Obligatoires
Scalabilité	Verticale	Horizontale
Cohérence	Forte	Éventuelle

---

Erreurs de débutants 🚨

❌ S’attendre à une exécution synchrone
❌ S’attendre à un rollback
❌ Embarquer du Java
❌ Modifier des variables comme dans une DB
❌ Traiter Zeebe comme Kafka
❌ Ignorer les pannes de workers

---

Quand Zeebe est le bon choix

✔ Systèmes cloud-native
✔ Microservices
✔ Fort débit
✔ Architectures événementielles
✔ Orchestration distribuée
✔ Nouveaux projets (greenfield)

---

Quand Zeebe n’est PAS le bon choix

❌ Workflows transactionnels lourds
❌ Exigences ACID strictes
❌ Systèmes très orientés tâches humaines
❌ Monolithes on-premise
❌ Équipes novices en asynchrone

---

Question d’entretien fréquente

Q : Qu’est-ce que le Zeebe Broker dans Camunda 8 ?
R : Un moteur BPMN distribué, basé sur un log, qui exécute les workflows via un modèle événementiel.

---

Conclusion

❗ Zeebe n’est pas “Camunda 7 en plus rapide”.
❗ C’est un modèle d’exécution totalement différent.

Si vous comprenez :

• Event sourcing

• Logs append-only

• Workers externes

• Cohérence éventuelle

Alors Zeebe est extrêmement puissant.

Sinon, Camunda 7 reste souvent un choix plus sûr.

💼 Support professionnel disponible

Si vous rencontrez des problèmes sur des projets réels liés au développement backend d’entreprise ou à l’automatisation des workflows, je propose des services de conseil payants, de débogage en production, de support projet et de formations ciblées.

Procédure commerciale

Les technologies couvertes incluent Java, Spring Boot, PL/SQL, Azure, ainsi que l’automatisation des workflows (jBPM, Camunda BPM, RHPAM), DMN/Drools.

📧 Contact: ishikhanirankari@gmail.com | info@realtechnologiesindia.com

🌐 Website: IT Trainings | Digital lectern | Digital rostrum | Digital metal podium