Camunda 8 Vs Temporal

Camunda 8 (BPMN + stream processing + RocksDB) y Temporal (code-first + durable execution + DB pluggable) son los dos approaches dominantes a workflow orchestration moderno. Camunda excele en human tasks y decision modeling (BPMN/DMN); Temporal excele en code-centric coordination de microservicios con queries directas y multi-region nativo. Para el MVP planeado (BPMN-required), tomar prestado de Temporal: single state store con direct queryability.

Decisión arquitectónica fundamental¶

flowchart TB
    subgraph Camunda[Camunda 8]
        C1[BPMN diagrams]
        C2[Engine interprets BPMN]
        C3[(RocksDB - embedded)]
        C4[Exporters to ES/SQL to UIs]
        C1 --> C2 --> C3 --> C4
    end
    subgraph Temporal[Temporal]
        T1[Code - Go/Java/TS/Python]
        T2[Engine executes your code]
        T3[(Pluggable DB<br/>Postgres/MySQL/Cassandra)]
        T4[Queries directas al engine]
        T1 --> T2 --> T3 --> T4
    end

Tabla de comparación detallada¶

Dimensión	Camunda 8 / Zeebe	Temporal
Workflow definition	BPMN 2.0 XML (visual)	Code (TypedSDK in Go/Java/TS/Python)
Authoring tool	Web Modeler, Desktop Modeler	IDE normal
Target audience	Business analysts + devs	Devs only
Engine execution	Interpreta BPMN	Ejecuta código directamente
State store	RocksDB embebido en broker	DB pluggable (Postgres/MySQL/Cassandra)
State queryability	Via exporters (eventual consistency)	Direct API queries
Visibility lag	Seconds (export pipeline)	Real-time
Versioning in-flight	Migration explícita (compleja)	`GetVersion()` markers en código
Signals	Message events + event-based gateways	Native signal API
Queries at runtime	NO (vía store secundario)	Native query handlers
Multi-region	NO native, setup manual	SÍ native replication
Horizontal scaling	Partitions + Raft (8192 max)	Shards + DB scaling
Performance	Single-digit ms por BPMN node	Sub-ms por activity
Failure recovery	Raft consensus + snapshots	DB durability
DMN support	Built-in (FEEL engine)	NO (external)
Human tasks	First-class (Tasklist)	Build it yourself
Process mining	Built-in (Optimize)	External tools
Connectors	~40 pre-built	Activities (write your own)

Cuándo elegir cada uno¶

Camunda 8 mejor cuando:¶

Human tasks son parte importante del workflow (compliance, approvals)
Business analysts modelan los procesos (no solo devs)
Compliance/audit requiere modelos visuales documentables
Decision tables (DMN) son requirement
Process mining integrado es valioso
Visual debugging de workflows en producción

Temporal mejor cuando:¶

Pure code teams (devs only)
Microservices coordination con lógica compleja conditional
Multi-region es requirement
Versioning de workflows long-running es crítico
Real-time visibility es esencial
Polyglot teams (Go + Python + TypeScript)

El "trade-off del modelo de workflow"¶

Pro de BPMN (Camunda)	Pro de Code (Temporal)
Visual, accesible a no-devs	Familiar para devs
Estándar industrial (compliance)	Type-safe en compile time
Stakeholder alignment más fácil	Refactor amigable
Decision tables nativas	Versioning natural (git)
Tools maduros (Modeler)	Testing con tools del lenguaje

Con de BPMN (Camunda)	Con de Code (Temporal)
Slower que código nativo	No visual para stakeholders
Spec compliance overhead	Solo para devs
Versionado runtime complejo	Sin standard inter-vendor
BPMN puede ser limitante	Polyglot SDK overhead

Patterns prestables de Temporal para el MVP¶

Aunque el MVP es BPMN-centric (Camunda-style), hay patterns de Temporal valiosos:

1. Single state store con direct queryability¶

flowchart LR
    subgraph C8[Camunda 8 - eventually consistent]
        CR[(RocksDB)] --> CE[Exporter] --> CES[(Elasticsearch)] --> CU[UI]
    end
    subgraph T[Temporal - strong consistent]
        TP[(Postgres)] --> TD[Direct query] --> TU[UI]
    end
    subgraph MVP[MVP plan - strong consistent]
        MP[(Postgres)] --> MD[Direct query] --> MU[UI]
    end

Eliminar el doble-store reduce 50% de la complejidad operacional.

2. Versioning markers¶

Aunque BPMN no soporta versioning runtime natural, considerar:

<bpmn:scriptTask id="task">
  <zeebe:script>
    if (process.version >= 2) {
      // new logic
    } else {
      // old logic
    }
  </zeebe:script>
</bpmn:scriptTask>

Permite "in-flight updates" sin migration formal.

3. Real-time query handlers¶

API para queries personalizadas contra el state actual de una instance:

GET /v2/process-instances/{key}/query/customStatus

Donde customStatus es una expresión FEEL evaluada en tiempo real contra las variables.

4. DB pluggable¶

Aunque PostgreSQL es la elección para MVP, dejar interface abierta:

interface StateStore {
  save(state: ProcessState): Promise<void>;
  load(key: string): Promise<ProcessState>;
  query(filter: Filter): AsyncIterator<ProcessState>;
}

// Implementations: PostgresStateStore, SQLiteStateStore, etc.

Lo que NO replicar de Temporal en el MVP¶

Code-first workflows: rompe el contrato BPMN del MVP
Polyglot SDK: ~1M LOC para mantener 4 lenguajes
Multi-region replication: out of MVP scope
In-flight versioning sin migration: complejidad muy alta

Mapeo de features Camunda 8 → MVP simplificado¶

Combinando las mejores ideas de ambos:

Feature	Camunda 8	Temporal	MVP
Workflow definition	BPMN ✓	Code	BPMN
State store	RocksDB + ES	Postgres	Postgres
Queryability	Via export	Direct	Direct
Visibility	Eventually consistent	Real-time	Real-time
Versioning	Migration	In-flight	Migration
Multi-region	Manual	Native	NO (single region)
Human tasks	First-class	DIY	First-class
DMN	Native	NO	Native
Connectors	~40	Activities	Workers (simple SDK)

El MVP toma de Camunda el modelo de negocio (BPMN, human tasks, DMN) y de Temporal la arquitectura de datos (single store, direct queries, real-time visibility).

Conclusión¶

Camunda y Temporal son ambos válidos pero optimizan diferentes dimensiones: - Camunda: business stakeholder + human task heavy + decision modeling - Temporal: dev-only + microservices coordination + multi-region

Para un MVP que aspira ser "drop-in replacement de Camunda 8 simplificado", el approach es: 1. Mantener BPMN/DMN/Tasklist (lo que diferencia a Camunda) 2. Adoptar single state store de Temporal (operacionalmente más simple) 3. Direct queries sin export pipeline obligatorio 4. Mantener job worker pattern (común a ambos) 5. Skip multi-region y in-flight versioning (no requeridos)

Esto da el 80% del valor de Camunda con 50% de la complejidad operacional.