Camunda 7 vs Camunda 8 Decision Framework

Fokus part ini: memberi framework keputusan arsitektur untuk membedakan Camunda 7 dan Camunda 8/Zeebe, bukan sekadar membandingkan fitur. Tujuannya agar Anda bisa membaca konsekuensi runtime, deployment, integration, reliability, migration, dan production operations.

Camunda 7 dan Camunda 8 bukan sekadar “versi lama” dan “versi baru”. Keduanya membawa model arsitektur yang berbeda.

Jika Anda hanya membandingkan UI atau BPMN symbol support, Anda akan melewatkan hal yang paling penting: execution semantics.

Untuk senior backend engineer, pertanyaan utamanya bukan:

“Mana yang lebih modern?”

Pertanyaan yang benar:

“Model eksekusi mana yang paling cocok untuk process ownership, service topology, data consistency, worker contract, deployment model, observability, operational responsibility, dan migration constraints kami?”

1. High-Level Comparison

2. Camunda 7 Architecture Decision Model

Camunda 7 is strongest when the system benefits from a Java process engine that is close to the application runtime.

Camunda 7 fits when

• the application is Java-centric;
• the team wants embedded/shared engine semantics;
• the process logic is tightly integrated with existing Java services;
• the organization already has Camunda 7 expertise;
• relational database operations are well understood;
• Cockpit/Tasklist operational model is already established;
• existing BPMN models use JavaDelegate/listeners heavily;
• external task pattern is already mature;
• migration cost to Camunda 8 is not justified yet;
• deployment topology is stable and controlled.

Camunda 7 becomes risky when

• process engine is embedded in too many application nodes without operational clarity;
• job executor tuning is not understood;
• process runtime database becomes overloaded;
• JavaDelegate performs non-idempotent side effects;
• BPMN deployment is coupled to application deployment without version discipline;
• long-running process state and business DB state diverge;
• incidents exist but no team owns them;
• history tables grow without cleanup;
• classloading/dependency issues appear during rolling deployment;
• support/EOL timeline creates strategic risk.

Typical Camunda 7 topology

+-------------------------------+
| Java/JAX-RS Application        |
|                               |
|  +-------------------------+  |
|  | Camunda 7 Process Engine |  |
|  +-------------------------+  |
|      | Runtime/History DB      |
+------|------------------------+
       v
+-------------------------------+
| PostgreSQL / RDBMS            |
| Camunda runtime/history tables|
+-------------------------------+

Optional:
- Cockpit
- Tasklist
- Optimize
- External task workers

This topology can be powerful, but it can also blur boundaries between application code, process runtime, and business state.

3. Camunda 8 / Zeebe Architecture Decision Model

Camunda 8 is strongest when process orchestration should be a platform-level capability and workers should be independently deployable.

Camunda 8 fits when

• processes span multiple services;
• worker services can be deployed independently;
• remote orchestration is acceptable;
• teams can operate distributed infrastructure;
• process execution needs horizontal scaling beyond a single app/database model;
• the architecture is already Kubernetes/cloud-native or hybrid-aware;
• workers can be designed idempotently;
• observability can span engine, gateway, worker, broker, search, and application logs;
• process ownership is mature;
• deployment pipeline can manage BPMN/DMN/forms/workers coherently.

Camunda 8 becomes risky when

• the team expects JavaDelegate-style local method invocation;
• worker idempotency is not understood;
• the organization cannot operate distributed runtime components;
• search/exporter dependency is ignored;
• network failure between worker and engine is not modelled;
• job timeout/retry/backpressure is not monitored;
• worker deployment is not compatible with process deployment;
• local development is too hard for engineers;
• process versioning and worker contract versioning are unmanaged;
• migration from Camunda 7 is treated as a mechanical library upgrade.

Typical Camunda 8 topology

+-------------------------------+
| Java/JAX-RS API Service        |
| - start process                |
| - correlate message            |
| - expose business API          |
+---------------|---------------+
                v
+-------------------------------+
| Camunda 8 / Orchestration      |
| - Zeebe runtime                |
| - Gateway/API                  |
| - Operate                     |
| - Tasklist                    |
| - Identity                    |
+---------------|---------------+
                v
+-------------------------------+
| Java Worker Services           |
| - activate jobs                |
| - call DB/API/Kafka/RabbitMQ   |
| - complete/fail jobs           |
+-------------------------------+

In this model, process orchestration is remote. Worker correctness becomes central.

4. Embedded Engine vs Distributed Engine

Embedded engine decision questions

Ask:

• Do we want engine lifecycle tied to application lifecycle?
• Do delegates need direct access to application beans?
• Do we understand transaction boundary between engine and business DB?
• Can we tune job executor safely?
• Can we operate the engine database?
• Can we manage rolling deployment safely?
• Can we avoid classpath and dependency issues?

Embedded engine is not automatically bad. It can be excellent for controlled enterprise Java systems. But it creates tight coupling.

Distributed engine decision questions

Ask:

• Can workers be idempotent?
• Can workers survive duplicate job execution?
• Can we monitor job activation latency?
• Can we operate broker/gateway/search dependencies?
• Can we handle network partitions?
• Can we design worker compatibility across process versions?
• Can we deploy workers and BPMN independently without mismatch?

Distributed engine is not automatically better. It creates stronger boundaries, but demands stronger operational maturity.

5. Database-Backed Runtime vs Log-Stream Runtime

Camunda 7 database-backed runtime

Camunda 7 persists runtime and history in relational database tables.

Implications:

• database is critical path;
• slow queries can affect execution;
• history level affects storage and performance;
• large variables can hurt database performance;
• job acquisition depends on database behavior;
• backup/restore needs RDBMS discipline;
• audit and retention can be handled through history tables, but must be managed.

Failure scenarios:

• DB connection pool exhaustion;
• job executor lag;
• transaction deadlock;
• optimistic locking exception;
• history table bloat;
• variable serialization failure;
• migration script failure;
• cleanup job overload.

Camunda 8 / Zeebe log-stream runtime

Zeebe uses a distributed processing model with broker state, partitions, and log/record concepts. Observability and query capabilities depend on exported data and platform components such as Operate and search infrastructure, depending on deployment/version.

Implications:

• broker health matters;
• partition leadership matters;
• gateway availability matters;
• exporter/search lag can affect UI visibility;
• worker activation depends on gateway/broker path;
• backpressure is a normal distributed-systems concern;
• snapshot/backup/restore has different semantics from relational DB restore.

Failure scenarios:

• broker unavailable;
• gateway unavailable;
• partition unhealthy;
• leader election instability;
• exporter lag;
• search dependency unhealthy;
• worker cannot activate jobs;
• Operate data appears stale;
• job timeout triggers duplicate work.

6. JavaDelegate vs External Task vs Zeebe Job Worker

This is one of the most important decision dimensions.

JavaDelegate

Used in Camunda 7.

Mental model:

Engine thread executes Java class directly.

Strengths:

• simple for Java teams;
• direct dependency injection;
• local method call;
• easy access to existing application services;
• fewer network hops.

Risks:

• tight coupling to engine runtime;
• classpath problems;
• transaction ambiguity;
• non-idempotent side effects hidden inside delegate;
• harder migration to Camunda 8;
• code may become invisible to platform operators.

Best suited for:

• local computation;
• simple service calls with clear retry behavior;
• tightly controlled Java application deployment;
• cases where embedding engine is intentional.

Bad fit for:

• unreliable external side effects;
• long external calls;
• heavy IO;
• integrations needing independent scaling;
• systems moving toward Camunda 8.

External Task

Used in Camunda 7.

Mental model:

Engine creates external task.
Worker fetches and locks task.
Worker completes/fails task.

Strengths:

• decouples worker from engine JVM;
• better microservice boundary;
• worker can be scaled independently;
• more migration-friendly toward Camunda 8 job workers;
• avoids embedding all integration code in engine runtime.

Risks:

• lock duration mistakes;
• worker crash after side effect;
• duplicate execution after lock expiration;
• poor backoff creates load;
• retry semantics split between worker and engine;
• topic naming/versioning must be governed.

Best suited for:

• service integration;
• external API calls;
• worker-per-domain-service pattern;
• migration-conscious Camunda 7 systems.

Zeebe Job Worker

Used in Camunda 8.

Mental model:

Zeebe creates job.
Worker activates job.
Worker performs work.
Worker completes/fails/throws BPMN error.

Strengths:

• natural distributed architecture;
• independent worker scaling;
• strong orchestration boundary;
• suitable for cloud-native/microservices;
• avoids engine embedding in business services.

Risks:

• idempotency is mandatory;
• timeout can trigger duplicate work;
• network failure affects command completion;
• worker compatibility with BPMN versions must be governed;
• concurrency/backpressure must be tuned;
• local debugging requires more setup.

Best suited for:

• microservices orchestration;
• long-running business process;
• independently deployable workers;
• cloud/hybrid systems;
• platform-level workflow runtime.

7. External Task vs Zeebe Job: Similar but Not Identical

External task and Zeebe job are conceptually similar but not identical.

Similarities:

• both use external workers;
• both require task/job type naming;
• both require completion/failure reporting;
• both need retry design;
• both need idempotency;
• both allow worker scaling.

Differences:

• Camunda 7 external task uses fetch-and-lock semantics;
• Camunda 8 job worker uses Zeebe job activation semantics;
• APIs are different;
• metadata and key semantics differ;
• timeout behavior differs in detail;
• failure commands differ;
• BPMN extension properties differ;
• operational tooling differs;
• migration requires code and BPMN conversion review.

Migration heuristic:

External task workers are often easier to migrate than JavaDelegates, but they are still not zero-effort migrations.

8. BPMN Support Difference

Both Camunda 7 and Camunda 8 support BPMN-based modelling, but supported elements, extension attributes, execution behavior, and migration compatibility must be verified per version.

Do not assume every Camunda 7 BPMN model runs unchanged on Camunda 8.

Review especially:

• JavaDelegate/service task implementation;
• listener usage;
• execution listener/task listener;
• script task;
• expression language;
• custom extension attributes;
• call activity binding;
• message correlation semantics;
• transaction subprocess;
• compensation;
• boundary events;
• multi-instance behavior;
• DMN integration;
• forms/user task implementation.

Decision rule:

If existing models rely heavily on Camunda 7-specific extensions, migration cost increases.

9. DMN Support Difference

DMN can exist in both worlds, but review:

• DMN engine integration;
• decision deployment;
• decision versioning;
• FEEL/expression support;
• business rule task configuration;
• test tooling;
• audit/history expectations;
• migration compatibility;
• operational visibility.

Decision rule:

DMN migration risk is not only table syntax. It includes how process variables, decision inputs, decision outputs, and audit expectations are wired into the process.

10. Human Task Difference

Human tasks are deceptively risky.

Compare:

Camunda 7

• Task Service;
• Tasklist;
• candidate users/groups;
• task listeners;
• form handling options;
• authorization model;
• history queries.

Camunda 8

• Tasklist;
• user task APIs depending on version;
• Identity integration;
• different operational/tooling model;
• form/task handling differences;
• different migration path for task-related code.

Review:

• custom task UI;
• task assignment rules;
• task completion API;
• task authorization;
• task audit;
• task SLA;
• task search;
• claim/unclaim behavior;
• stale task behavior.

Decision rule:

If the product has a mature custom task UI built around Camunda 7 Task Service semantics, human task migration can be a major workstream.

11. Operational Tooling Difference

Camunda 7 tooling

• Cockpit for process operations;
• Tasklist for user tasks;
• Admin/identity capabilities depending on setup;
• Optimize if used;
• database-level inspection often relevant;
• application logs and job executor metrics important.

Camunda 8 tooling

• Operate for process instance/incident visibility;
• Tasklist for human tasks;
• Identity for access;
• Optimize if used;
• Console/Web Modeler depending on deployment model;
• broker/gateway metrics important;
• exporter/search health important;
• worker metrics essential.

Decision rule:

Migration changes the operator experience. Train SRE/support/backend teams before moving critical process workloads.

12. Scalability Model Difference

Camunda 7 scalability model

Main scaling levers:

• application nodes;
• job executor thread pool;
• async boundary placement;
• database performance;
• history level;
• cleanup strategy;
• external task worker scaling;
• connection pool tuning.

Bottlenecks often appear in:

• database;
• job acquisition;
• locks;
• history writes;
• variable serialization;
• large process models;
• excessive timer/jobs.

Camunda 8 scalability model

Main scaling levers:

• Zeebe broker resources;
• partition count;
• gateway resources;
• worker concurrency;
• max jobs active;
• job timeout;
• exporter throughput;
• search/indexing capacity;
• Tasklist/Operate load;
• Kubernetes resources and placement.

Bottlenecks often appear in:

• worker throughput;
• broker backpressure;
• partition imbalance;
• exporter lag;
• search dependency;
• network latency;
• payload size.

Decision rule:

Camunda 8 does not eliminate capacity planning. It moves capacity planning from relational database/job executor thinking to distributed runtime/worker/search thinking.

13. Deployment Model Difference

Camunda 7 deployment questions

• Is BPMN packaged in the Java application?
• Is deployment performed at application startup?
• Is there a shared engine deployment model?
• Are process applications used?
• How are JavaDelegates deployed?
• What happens during rolling deployment?
• Can old jobs call classes that no longer exist?
• Are process definition versions compatible with deployed code?

Camunda 8 deployment questions

• Are BPMN/DMN/forms deployed separately from workers?
• How are workers versioned?
• Can old process versions still activate old job types?
• Are job types backward compatible?
• Are variables backward compatible?
• Are messages/correlation keys stable?
• Does GitOps deploy platform and workers separately?
• What is rollback strategy if process deployment succeeds but worker deployment fails?

Decision rule:

In Camunda 8, BPMN-worker compatibility is a first-class deployment concern.

14. Migration Challenge

Migration from Camunda 7 to Camunda 8 is not a normal dependency upgrade.

It may require changes in:

• BPMN extension attributes;
• service task implementation;
• JavaDelegate replacement;
• external task worker replacement;
• listener logic;
• process variable serialization;
• API usage;
• task UI integration;
• identity/authorization;
• deployment pipeline;
• operational runbooks;
• test strategy;
• incident handling;
• process instance migration;
• monitoring dashboards.

Migration should be treated as a program, not a refactor.

15. When Camunda 7 Fits

Camunda 7 can still fit when:

• existing production system is already stable on Camunda 7;
• migration cost is high and not justified immediately;
• process volume is manageable;
• database operations are mature;
• team understands job executor and history cleanup;
• JavaDelegate/external task patterns are controlled;
• support/license timeline is acceptable;
• compliance requirements depend on existing audit/history behavior;
• near-term business priority is stability, not platform migration.

But the decision must include support lifecycle and strategic direction.

Ask:

• Are we allowed to remain on Camunda 7 under current enterprise support?
• What is our timeline to evaluate Camunda 8?
• Which models are migration blockers?
• Which delegates/listeners would need replacement?
• Which process instances are long-running beyond migration windows?

16. When Camunda 8 Fits

Camunda 8 fits when:

• new workflow platform is being introduced;
• distributed orchestration is desired;
• workers can be owned by domain teams;
• process volume or topology benefits from Zeebe architecture;
• Kubernetes/cloud-native operation is available;
• teams can implement idempotent workers;
• observability stack is mature;
• process artifacts can be managed through CI/CD;
• human task and identity requirements match Camunda 8 capabilities;
• organization wants long-term alignment with Camunda platform direction.

Ask:

• Can we operate Zeebe reliably?
• Can we monitor broker/gateway/exporter/search/worker health?
• Can we design job worker idempotency?
• Can we keep worker versions compatible with process versions?
• Can developers run workflow locally or in dev environments?

17. When Neither Fits

Sometimes the right answer is not Camunda.

Camunda may be too heavy if:

• the process has only one synchronous step;
• there is no long-running state;
• there is no human task;
• there is no need for process visibility;
• there is no compensation/escalation;
• a simple state machine is sufficient;
• a scheduler is sufficient;
• a queue consumer is sufficient;
• event choreography is already clear and observable;
• business users do not need process diagrams;
• operational team cannot support workflow incidents.

Use alternatives:

Decision rule:

A workflow engine is justified by explicit process complexity, not by architectural fashion.

18. Decision Matrix

Use this matrix as a quick architecture review tool.

19. Decision Questions for Architecture Review

Business/process questions

• What business process are we modelling?
• Is the process long-running?
• Are there human tasks?
• Are there SLA timers?
• Are there compensating actions?
• Is process visibility required by support/business teams?
• Is BPMN a communication artifact with BA/product?

Technical questions

• Which services participate?
• Which database tables are updated?
• Which events are produced/consumed?
• What is the source of truth for entity state?
• What is the process business key?
• What is the correlation key?
• Are workers idempotent?
• Are retries safe?

Operational questions

• Who owns incidents?
• Where are incidents visible?
• Who can retry failed work?
• What dashboard detects stuck process instances?
• How is task aging monitored?
• How is SLA breach detected?
• What is the manual repair procedure?

Deployment questions

• How is BPMN deployed?
• How are workers deployed?
• Can process and worker versions drift?
• What happens to running instances during deployment?
• Is rollback possible?
• Is process migration required?

Security questions

• Who can start process instances?
• Who can view variables?
• Who can complete user tasks?
• Are sensitive variables stored?
• Are logs redacted?
• Are worker credentials scoped?
• Is tenant isolation required?

20. CSG-Oriented Decision Lens

For CSG Quote & Order context, think in terms of enterprise process pressure.

Potential workflow-worthy areas:

• quote approval;
• pricing override approval;
• contract approval;
• order validation;
• order decomposition;
• fulfillment orchestration;
• fallout management;
• amendment;
• cancellation;
• renewal;
• manual intervention;
• SLA escalation;
• reconciliation.

But do not assume actual CSG architecture.

For each candidate process, ask:

1. Is there already a workflow engine?
2. Is BPMN used as executable model or documentation only?
3. Is quote/order state managed by workflow, database state machine, or both?
4. Which service owns the worker/delegate logic?
5. Which process steps touch PostgreSQL/MyBatis/JDBC?
6. Which steps publish or consume Kafka/RabbitMQ messages?
7. Is Redis part of idempotency/locking/caching?
8. How are incidents detected and resolved?
9. Who owns manual task aging?
10. What is the process deployment and rollback process?

21. Common Bad Decisions

Bad decision 1: Choosing Camunda 8 because it is newer

Wrong reason.

Better reason:

• remote orchestration is desired;
• worker model fits service topology;
• team can operate distributed runtime;
• migration path is understood;
• process-worker contract is governed.

Bad decision 2: Staying on Camunda 7 because migration is hard

Potentially wrong reason.

Better reason:

• current system is stable;
• support timeline is acceptable;
• migration risk is understood;
• migration roadmap exists;
• business priority justifies staged adoption.

Bad decision 3: Using Camunda for every async flow

Wrong reason.

Use Camunda when process visibility, long-running orchestration, human task, compensation, or audit justify it.

Use queue/scheduler/state machine for simpler cases.

Bad decision 4: Migrating JavaDelegates mechanically to job workers

Wrong reason.

A job worker has different failure semantics. You must redesign:

• idempotency;
• transaction boundary;
• retry;
• timeout;
• completion failure;
• duplicate side effects;
• observability.

Bad decision 5: Treating process variables as database records

Wrong reason.

Use variables for orchestration context. Use business database for domain state.

22. Failure Mode Comparison

23. Internal Verification Checklist

Actual platform

• Is Camunda used?
• Which version?
• Is it Camunda 7 Enterprise, Camunda 8 SaaS, Camunda 8 self-managed, or mixed?
• Is there an ongoing migration?
• What is the support/licensing constraint?

Camunda 7-specific

• Is process engine embedded or shared?
• Are JavaDelegates used?
• Are ExecutionListeners or TaskListeners used?
• Are external tasks used?
• Is job executor enabled on all nodes or selected nodes?
• What database stores runtime/history?
• What is history level?
• How is history cleanup configured?
• Is Cockpit used for incidents?
• Is Tasklist used for human tasks?

Camunda 8-specific

• Is Zeebe self-managed or SaaS?
• What is the broker/gateway topology?
• What is the partition count?
• Are workers deployed separately?
• What job types exist?
• Are Connectors used?
• Is Operate used for triage?
• Is Tasklist used for human tasks?
• How is Identity configured?
• What search/exporter dependency exists?

Worker/delegate design

• Which steps call external APIs?
• Which steps write PostgreSQL?
• Which steps publish Kafka/RabbitMQ events?
• Which steps use Redis?
• Which steps are idempotent?
• Which steps can safely retry?
• Which steps require manual repair?

Deployment and versioning

• Where are BPMN/DMN files stored?
• How are process definitions deployed?
• How are workers deployed?
• Is process version pinned or latest?
• Are worker contracts versioned?
• How are running instances handled?
• Is migration supported?
• Is rollback tested?

Operations

• Where are incidents visible?
• Who owns incidents?
• What is the retry policy?
• What metrics exist for job latency and worker failure?
• What alert exists for stuck process?
• What alert exists for task aging?
• What runbook exists for manual repair?

24. Architecture Recommendation Pattern

When asked “Should we use Camunda 7 or Camunda 8?”, answer using this structure.

1. Process requirement
   - What process complexity justifies workflow?

2. Current platform reality
   - What exists today?
   - What support/migration constraint exists?

3. Runtime fit
   - Embedded Java engine vs remote orchestration?

4. Worker model
   - JavaDelegate/external task vs Zeebe job worker?

5. Data consistency
   - Business DB, process variables, outbox/inbox, idempotency?

6. Operations
   - Incident ownership, monitoring, runbook, retry policy?

7. Deployment/versioning
   - BPMN, worker, running instance, rollback, migration?

8. Security/compliance
   - Task access, variable privacy, audit, tenant isolation?

9. Recommendation
   - Camunda 7 / Camunda 8 / neither / phased migration.

10. Risks and mitigations
   - Explicitly list failure modes and required controls.

This prevents technology-first decisions.

25. Practical Recommendation Heuristics

Prefer Camunda 7 when

• existing Camunda 7 system is stable;
• Java integration is central;
• migration is not yet justified;
• operational team understands DB/job executor/Cockpit;
• support timeline is acceptable;
• external task pattern can reduce coupling gradually.

Prefer Camunda 8 when

• starting new strategic workflow platform;
• remote orchestration fits microservices;
• workers can be independently owned and scaled;
• Kubernetes/cloud platform maturity exists;
• team can design idempotency and observability;
• long-term platform direction matters.

Prefer neither when

• flow is simple;
• no human task;
• no long-running orchestration;
• no process visibility needed;
• state machine, scheduler, queue, or event choreography is enough;
• operational ownership for workflow is absent.

26. Reference Anchors

Use official documentation as source of truth for version-specific differences:

• Camunda 8 Self-Managed components: https://docs.camunda.io/docs/self-managed/about-self-managed/
• Camunda 8 8.8 release notes and Orchestration Cluster architecture change: https://docs.camunda.io/docs/reference/announcements-release-notes/880/880-release-notes/
• Camunda 8 reference architecture: https://docs.camunda.io/docs/self-managed/reference-architecture/
• Camunda 7 documentation: https://docs.camunda.org/
• Camunda 7 Enterprise release policy: https://docs.camunda.org/enterprise/release-policy/
• Camunda 7 to 8 migration tooling: https://docs.camunda.io/docs/8.7/guides/migrating-from-camunda-7/migration-tooling/
• Camunda 7 to 8 code conversion guidance: https://docs.camunda.io/docs/guides/migrating-from-camunda-7/migration-tooling/code-conversion/

27. Part Summary

Camunda 7 and Camunda 8 solve related problems with different architecture.

Key takeaways:

• Camunda 7 is a Java BPMN process engine with database-backed runtime.
• Camunda 8 is a distributed orchestration platform built around Zeebe and external workers.
• JavaDelegate and Zeebe job worker are not equivalent operationally.
• External task is closer to Zeebe job worker, but migration is still not automatic.
• Camunda 7 scaling is often DB/job-executor/application-node centric.
• Camunda 8 scaling is broker/partition/gateway/worker/exporter/search centric.
• Human task, DMN, API, identity, and tooling differences matter.
• Migration is a program, not a dependency bump.
• Sometimes neither Camunda 7 nor Camunda 8 is the right tool.

The next part will go deeper into BPMN execution mental model: process definition, process instance, token, activity, gateway, event, variable, job, incident, wait state, transaction boundary, completion, and termination.