Learn IT with Shikha Blogs

Zeebe Architecture Overview ✍️ Introduction If you’re coming from Camunda 7 (DB-based engine) , understanding how Camunda 8 (Zeebe) stores workflow state is a game changer . Instead of storing process state in a relational database, Zeebe uses a distributed event-driven architecture — making it: ⚡ Highly scalable 🔁 Fault tolerant 🚀 Extremely fast 👉 Let’s break this down in a simple, practical way . 🧩 1. Core Idea: Event-Sourced State In Zeebe: ❌ No central database ✅ Workflow state = event stream (log of events) Every action in a workflow becomes an event : Process started Task activated Variable updated Task completed These events are written sequentially to a log . 📌 This is similar to Kafka-style architecture. 👉 Zeebe stores state as event streams on disk across brokers 🖼️ Event Stream Concept ⚙️ 2. How State is Actually Stored Let’s simplify: 🧱 Step-by-step Client sends command → via Gateway (REST/gRPC) Gateway routes to a Broker Broker writes an event: PROCESS_INSTANCE_C...

🖼️ Vue d’ensemble de l’architecture Zeebe ✍️ Introduction Si vous venez de Camunda 7 (basé sur base de données) , comprendre comment Camunda 8 (Zeebe) stocke l’état des workflows est essentiel. Contrairement à Camunda 7 : ❌ Pas de base de données centrale ✅ Utilisation d’une architecture distribuée basée sur les événements 👉 Résultat : ⚡ Haute performance 🔁 Tolérance aux pannes 🚀 Scalabilité horizontale 🧩 1. Concept clé : Event Sourcing Dans Zeebe : L’état du workflow = suite d’événements (event stream) Chaque action devient un événement : Démarrage du processus Activation d’une tâche Mise à jour des variables Fin d’une tâche 👉 Tous ces événements sont stockés dans un log append-only 🖼️ Concept de flux d’événements ⚙️ 2. Comment l’état est stocké concrètement 🧱 Étapes simplifiées Le client envoie une requête (via Gateway) La Gateway redirige vers un Broker Le Broker écrit un événement : PROCESS_INSTANCE_CREATED TASK_ACTIVATED VARIABLE_UPDATED L’événement est : Stocké dans un l...