Temporal vs Zeebe: Melyik workflow engine-et válasszam?

Ez a post nem fog olyan lenni, mint a többi...

Tudom, már megint egy workflow engine összehasonlítás. "Válasszad, melyik a jobb!" - mintha egy házasság lenne.

De az igazság az, hogy a Temporal és a Zeebe két teljesen más filozófia. Az egyik úgy működik, hogy írsz egy kódot és az lefut. A másik úgy, hogy rajzolsz egy sémát és a rendszer futtatja.

Én mind a kettőt használtam élesben, és az alábbiakban leírom, mit tapasztaltam. Nem vendor marketing, hanem az a fajta összehasonlítás, amit a kávé mellett szoktunk megbeszélni.

---

🎯 TL;DR (ha nem akarsz végigolvasni)

---

🔑 Key Topics Covered

• Mi a workflow engine, és miért kell?
• Code-as-a-workflow vs BPMN-as-a-workflow
• Temporal: Uber Cadence-ből, developer-first
• Zeebe (Camunda 8): BPMN 2.0, cloud-native
• Architektúra és scaling
• Kód példák (order feldolgozás)
• Tooling (Camunda Modeler, Temporal UI)
• Mikor melyiket válasszuk
• Összefoglaló táblázat
• Q&A (gyakori kérdések)

---

🤔 Mi a workflow engine? És miért nem elég a message queue?

Kérdés: " Már eddig is működött a rendszer, mi a szükség egy workflow engine-re?"

Rendezetlen válasz: Igen, amíg egyszerű a folyamat. De...

code
1Korai szakasz:
2  User → API → DB → Email
3  Mennyi kód? 50 sor.
4  Mi történik, ha a DB transaction failol email után?
5  ...
6
7Későbbi stádium:
8  User → API → Validate → Stock → Payment → Ship → Email → SMS → Invoice → Analytics
9  Mennyi kód? 2000 sor.
10  Mi van, ha a payment gateway timeout-ot ad 3. try-nál?
11  Mi van, ha a user 2 nap múlva vissza akarja vonni?
12  Mi van, ha a shipping service 2x hívja be magát (retry)?

A message queue (Kafka, RabbitMQ) arra jó, hogy A pontból B-be jusson az üzenet. De ha:

• Retry kell idempotent módon
• State-et kell menteni (hol tart a folyamat?)
• Kompenzáció kell (ha fail, visszafelé)
• Human approval kell (pl. manager approve)
• Timeout kell (ha 24 óra alatt nincs payment, cancel)

...akkor workflow engine kell.

---

🏗️ Code-as-a-Workflow vs BPMN-as-a-Workflow

Ez a két ellentétes filozófia. És ez a legnagyobb különbség mind a kettő között.

BPMN-as-a-Workflow (Zeebe)

A BPMN (Business Process Model and Notation) egy szabvány - 2004 óta létezik. Úgy néz ki, mint egy metrótérkép. Van benne:

Ez a graphical megközelítés. A business analyst is érti (ha ért a BPMN-hez). A folyamat látható.

Előnyök:

• Vizuális - mindenki látja, mi a folyamat
• Szabványos - van BPMN tudású ember
• Business logic és code split - a PM definiálja, a developer implementálja

Hátrányok:

• A "code nem úgy fut le, ahogy a graph néz ki" - van hidden state
• Kevesebb language support - Java vagy external worker
• A debugging úgy van, hogy "melyik token hol van?"

Code-as-a-Workflow (Temporal)

A Temporal azt mondja: "Írd le a workflow-t kódban, mi meg lefuttatjuk."

go
1// Temporal workflow - sima Go kód
2func PaymentWorkflow(ctx workflow.Context, order Order) error {
3    options := workflow.ActivityOptions{
4        StartToCloseTimeout: 5 * time.Minute,
5        RetryPolicy: &temporal.RetryPolicy{
6            InitialInterval:    time.Second,
7            BackoffCoefficient: 2,
8            MaximumAttempts: 3,
9        },
10    }
11    ctx = ctx.WithActivityOptions(options)
12
13    // 1. Készlet ellenőrzés
14    var stockErr stock.CheckResponse
15    if err := ctx.ExecuteActivity(
16        stock.Check, order.Items, &stockErr,
17    ).Get(ctx, &stockErr); err != nil {
18        return err // Automatic retry
19    }
20    if stockErr.NotAvailable {
21        return ctx.CreateTimer(time.Hour).Get(ctx, nil) // Wait 1 hour
22    }
23
24    // 2. Fizetés
25    var paymentResp payment.ProcessResponse
26    if err := ctx.ExecuteActivity(
27        payment.Process, order.Payment, &paymentResp,
28    ).Get(ctx, &paymentResp); err != nil {
29        // Kompenzáció: készlet vissza
30        ctx.ExecuteActivity(stock.Release, order.Items)
31        return err
32    }
33
34    // 3. Szállítás
35    ctx.ExecuteActivity(shipping.Create, order.Shipping)
36
37    return nil
38}

Ez ugyanúgy néz ki, mint a normál kód. Csak "durable" - ha az app crash-el,recovery után ott folytatja, ahol abbahagyta.

Előnyök:

• Ugyanúgy debug-olod, mint a normál kódot
• Teljes kontroll - minden logika kódban van
• Multi-language - Go, Java, TypeScript, Python
• Beépített retry, timeout, kompenzáció

Hátrányok:

• Nincs vizuális - code-only, a PM nem látja a folyamatot
• Learning curve - meg kell érteni a durable execution-t
• "Miért nem csak sima kód?" - magyarázkodni kell

---

🔥 Temporal: A Developer-First Megoldás

A Temporal a Uber Cadence-ből született. Aztán a Cadence fejlesztői kiléptek és csináltak egy Temporal-t, ami jobb (szerintük).

Főbb jellemzők:

• Durable execution - ha a worker crash-el, recovery után ott folytatja
• Event history - minden state change mentve van, replay-elhető
• Multi-language SDK - Go, Java, TypeScript, Python (beta)
• Beépített retry - nem kell wrapper
• Signals - küldhetsz üzenetet futó workflow-nak
• Queries - lekérdezheted a futó workflow state-jét
• Timer - beépített delay/wait

Amit szeretek benne:

1. Retry beépítve - RetryPolicy az ActivityOptions-ben, automatic
2. Queries - client.QueryWorkflow() - le tudod kérdezni a futó state-et
3. Signals - küldhetsz signal-t futó workflow-nak, pl. "cancel"
4. Activity registration - bármilyen function-t regisztrálsz, az lesz az activity

Amit nem szeretek benne:

1. Learning curve - meg kell érteni a durable execution modellt
2. Debug - nem olyan egyszerű, mint a sima kódot debug-olni
3. No visual - a PM nem látja, mit rajzoltál

---

🎭 Zeebe (Camunda 8): A BPMN Megoldás

A Zeebe a Camunda 8 engine-je. A Camunda 7 (Java, monolithic) utódja, cloud-native és horizontálisan skálázható.

Főbb jellemzők:

• BPMN 2.0 - szabványos folyamatmodell
• Camunda Modeler - grafikus editor (Web/Desktop)
• Partitions - horizontális scaling, minden partition önálló
• Job workers - external service hívások
• Operate - monitoring UI
• Elasticsearch exporter - history és analytics
• Decision (DMN) - és Decision-t is tud (Drools)

Amit szeretek benne:

1. BPMN - szabványos, mindenki érti
2. Operate UI - látod a folyamatot, hol tart
3. DMN - decision table, nem csak flow
4. Operátorok is értik - PM, BA is nézik

Amit nem szeretek benne:

1. External workers - a worker-ek külön process-ek
2. Elasticsearch kell - extra infrastructure
3. No built-in retry - magad implementálod
4. Kevesebb language - Java-fókuszú

---

📊 Architektúra Összehasonlítás

---

💻 Kód Példák

Order Feldolgozás - Temporal

go
1// Order workflow - Temporal
2func OrderWorkflow(ctx workflow.Context, order OrderInput) error {
3    ao := workflow.ActivityOptions{
4        StartToCloseTimeout: 5 * time.Minute,
5        RetryPolicy: &temporal.RetryPolicy{
6            InitialInterval:    time.Second,
7            BackoffCoefficient: 2,
8            MaximumAttempts: 5,
9        },
10    }
11    ctx = ctx.WithActivityOptions(ao)
12
13    // 1. Validate
14    var validOrder Order
15    if err := ctx.ExecuteActivity(
16        ValidateOrder, order, &validOrder,
17    ).Get(ctx, &validOrder); err != nil {
18        return err
19    }
20
21    // 2. Stock check
22    var stockResp StockResponse
23    if err := ctx.ExecuteActivity(
24        CheckStock, validOrder.Items, &stockResp,
25    ).Get(ctx, &stockResp); err != nil {
26        return err
27    }
28    if !stockResp.Available {
29        // Wait and retry
30        t := ctx.CreateTimer(30 * time.Minute)
31        t.Get(ctx, nil)
32        return temporal.ErrRetry
33    }
34
35    // 3. Payment
36    var paymentResp PaymentResponse
37    if err := ctx.ExecuteActivity(
38        ProcessPayment, validOrder.Payment, &paymentResp,
39    ).Get(ctx, &paymentResp); err != nil {
40        // Compensate: release stock
41        ctx.ExecuteActivity(ReleaseStock, validOrder.Items)
42        return err
43    }
44
45    // 4. Shipping
46    ctx.ExecuteActivity(CreateShipping, validOrder.Shipping)
47
48    return nil
49}
50
51// Activities
52func ValidateOrder(ctx context.Context, input OrderInput, output *Order) error {
53    // validation logic
54    return nil
55}
56
57func ProcessPayment(ctx context.Context, payment PaymentInfo, resp *PaymentResponse) error {
58    // payment gateway call
59    return nil
60}

Order Feldolgozás - Zeebe (BPMN)

xml
1<!-- order-process.bpmn -->
2<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
3              xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
4              xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
5              xmlns:zeebe="http://camunda.io/schema/zeebe-elements">
6
7  <process id="order-process" isExecutable="true">
8    <startEvent id="start" />
9    <sequenceFlow sourceRef="start" targetRef="validate" />
10
11    <serviceTask id="validate" name="Validate Order">
12      <extensionElements>
13        <zeebe:taskDefinition type="order:validate" />
14      </extensionElement>
15    </serviceTask>
16    <sequenceFlow sourceRef="validate" targetRef="check-stock" />
17
18    <serviceTask id="check-stock" name="Check Stock">
19      <extensionElements>
20        <zeebe:taskDefinition type="order:check-stock" />
21      </extensionElement>
22    </serviceTask>
23    <sequenceFlow sourceRef="check-stock" targetRef="process-payment">
24      <conditionExpression>available == true</conditionExpression>
25    </sequenceFlow>
26    <sequenceFlow sourceRef="check-stock" targetRef="not-available">
27      <conditionExpression>available == false</conditionExpression>
28    </sequenceFlow>
29
30    <serviceTask id="process-payment" name="Process Payment">
31      <extensionElements>
32        <zeebe:taskDefinition type="payment:process" />
33      </extensionElement>
34    </serviceTask>
35    <sequenceFlow sourceRef="process-payment" targetRef="shipping" />
36
37    <serviceTask id="shipping" name="Create Shipping">
38      <extensionElements>
39        <zeebe:taskDefinition type="shipping:create" />
40      </extensionElement>
41    </serviceTask>
42    <sequenceFlow sourceRef="shipping" targetRef="end" />
43
44    <endEvent id="end" />
45    <endEvent id="not-available" />
46  </process>
47</definitions>

go
1// Zeebe worker (GO)
2func main() {
3    client, _ := zeebe.NewClient(zeebe.ClientOptions{
4        GatewayAddr: "localhost:26500",
5    })
6
7    worker, _ := client.NewWorker(zeebe.JobWorkerOptions{
8        Type: "order:check-stock",
9        Handler: func(ctx zeebe.JobContext, variables Variables) (Variables, error) {
10            // Check stock
11            available := checkStockDB(variables["productId"])
12
13            return map[string]interface{}{
14                "available": available,
15            }, nil
16        },
17    })
18
19    worker.Start()
20}

A különbség a kódban:

---

🔧 Tooling

Temporal

bash
1# CLI
2temporal workflow list
3temporal workflow describe --workflow_id=xxx
4temporal workflow stacktrace --workflow_id=xxx
5temporal task queue describe
6
7# Web UI
8temporal web --port 8088
9
10# VS Code
11Temporal Workflow Analyzer extension

Zeebe (Camunda 8)

bash
1# Camunda Operate
2# Web: localhost:8080
3
4# Modeler
5camunda modeler desktop app
6# Vagy web: modeler.cloud.camunda.io
7
8# CLI
9zbctl deploy process order.bpmn
10zbctl create instance order-process

---

🎯 Mikor melyiket?

Válassz Temporal-t, ha:

1. Szeretsz kódot írni - nem grafikus tool-t
2. Multi-language kell - Go, Python, TypeScript SDK
3. Mission-critical - beépített retry, recovery fontos
4. Microservice orchestration - service-to-service hívások
5. Fejlesztői csapat - nem kell PM/BA nézés
6. Quick start - Docker, kubectl, start

🎯 Valós Use Case-ek

Gyakorlati példák, ahol én használtam:

1. Kubernetes Cluster Provisioning

• Node-ok provisioningja, load balancer config, DNS setup
• Ha worker crash, ott folytatja
• Timeout + retry minden lépésnél

2. Infrastructure as Code Deployment

• Multi-step deploy: build → test → staging → production
• Manual approval gate-ek közt
• Rollback capability

3. Data Pipeline Orchestration

• Extract → Transform → Load → Validate → Notify
• Scheduled run-ok, retry policy
• State replay ha failol

4. Payment & Billing (Zeebe preferált)

• Recurring payments, subscription management
• Invoice generálás, küldés, retry
• Refund, chargeback handling
• Kampány/discount engine

Válassz Zeebe-t (Camunda 8), ha:

1. BPMN-t akarsz - graphical workflow kell
2. Van Camunda 7 tudásod - legacy migráció
3. Business analyst-ok is nézik - látható folyamat
4. Decision (DMN) kell - decision table-t használtok
5. Java-fókuszú a csapat - Camunda SDK
6. Operate kell - vizuális monitoring
7. Payment/Billing - recurring payments, invoicing (DMN decision table + BPMN)

A döntés nem mindig egyértelmű

code
1Ha új projekt vagy:
2   └─ Van BPMN tudásod? → Igen → Zeebe
3   └─ Nincs BPMN? → Milyen a csapatod?
4       └─ Developer-only → Temporal
5       └─ Developer + PM → Zeebe
6
7Ha meglévő rendszer:
8   └─ Camunda 7 van? → Zeebe (migráció)
9   └─ Semmi? → Mi fontosabb?
10        └─ Retry, recovery → Temporal
11        └─ Visual → Zeebe

📊 Összefoglaló Táblázat

🏁 Conclusion

A Temporal és a Zeebe is jó választás, de nem mindegyik minden helyzetre.

Temporal jobb, ha:

• Szeretnéd kódban tartani a business logic-ot
• Multi-language SDK kell (Go, Python, TS)
• Mission-critical retry és recovery fontos
• Kis csapat, developer-only
• Gyors start kell (container)

Zeebe (Camunda 8) jobb, ha:

• BPMN workflow kell (vizuális)
• Van Camunda 7 legacy
• Business analyst-ok is nézik a folyamatot
• Decision (DMN) kell
• Java stack

A legtöbb esetben Temporal az iff új projekt, kód-alapú megközelítés. De ha a szervezet BPMN-t követel, akkor Zeebe.

Én személy szerint mind a kettőt használom. A Temporal-t a backend orchestration-ra, a Zeebe-t ott, ahol a PM-ek vizuális folyamatot akarnak látni.

Az nincs "egyetlen jobb". Mind a kettő másra jó.

Q&A - Gyakori Kérdések

Q: A Temporal nem egyszerűbb lenne, mint Zeebe?

A:

Igen is, meg nem is. A Temporal beépített retry, timeout, compensation - szóval kevesebb boilerplate. DE meg kell érteni a durable execution-t, ami nem triviális. A Zeebe-nél a BPMN-t kell megtanulni, de az egy szabvány, van könyv róla.

Ha kódot szeretsz írni: Temporal. Ha grafikus szeretsz: Zeebe.

Q: Migrálható-e Zeebe-ről Temporal-ra?

A:

Nem, nem automatikus. A BPMN-t át kell írni kódra. Ez egy elég nagy refactoring. De a koncepciók átültethetők (task = activity, flow = workflow).

Ha már van Zeebe-d és működik: maradj Zeebe-nél. Ha új projekt: Temporal Egyszerűbb start.

Q: Mi a különbség a Camunda 7 és 8 között?

A:

Camunda 7: monolith Java app, embedded engine, jobb small deployment.

Camunda 8 (Zeebe): cloud-native, Kubernetes, horizontálisan skálázható, Operate UI, de új architektúra.

Ha van Camunda 7: 8-ra migráció nagyobb upgrade. Ha nothing: mind a kettő közül 8-as jobb új projektnek.

Q: Melyik jobb hosszú-running workflow-kra?

A:

Temporal. Beépített timer-ekkel és state-mentéssel évekig is futhat. A Zeebe-nél a long-running workflow-k Elasticsearch-be kerülnek, és nem annyira triviális a query.

Ha "order + payment + 30 nap múlva reminder + 90 nap múlva close" -> Temporal

Q: Human-in-the-loop kell mind a kettőnél?

A:

Zeebe: Igen, beépített Tasklist, human tasks.

Temporal: Nem annyira native, de lehet csinálni signal-lal (user approve), vagy külső UI-t.

Ha "manager approval" fontos: Zeebe.

Q: Melyik skálázik jobban?

A:

Mind a kettő horizontálisan skálázódik. Zeebe: partitions. Temporal: worker-ek.

De a Temporal-nál a "durability" overhead van, szóval alacsonyabb throughput, de megbízhatóbb. Zeebe: nagyobb throughput, de "at-least-once" - neked kell idempotent.

Q: Le lehet-e cserélni az Airflow-t Temporal-ra?

A:

Nem, más kategóriák. Airflow = batch ETL, dátum alapú scheduling, cron alternatíva. Temporal = service orchestration, hosszú-running, retry.

Ha "napi ETL pipeline" -> Airflow. Ha "microservice hívások + retry + recovery" -> Temporal.

Q: Egyik sem jó, mi más van?

A:

• Conductor (Netflix): YAML-alapú, más filozófia
• Prefect: Python-native, batch ETL-re
• Kestra: YAML, ETL/data pipeline-ra
• Cadence: Temporal elődje, csak Go + Java

Ha ETL: Airflow, Prefect, Kestra. Ha orchestration: Temporal, Conductor. Ha BPMN: Camunda, Flowable.

Have questions about this topic?

We are happy to discuss your specific needs. Whether you need architecture advice, implementation guidance, or just want to explore possibilities.

Let's Talk

Ez a post 2026. április 15-én íródott. Az információ addig igaz, amíg valaki ki nem ad egy új verziót, ami mindent megváltoztat.