Camunda 8 Vs Conductor

Camunda 8 (BPMN XML + RocksDB + Raft) y Netflix Conductor (JSON + external DB) son dos approaches viables a workflow orchestration. Camunda apunta a enterprise compliance y business analysts; Conductor a dev-only microservices coordination. Conductor tiene built-in tasks (HTTP, DECISION, DO_WHILE) que Camunda requiere implementar como workers. Para MVP "drop-in replacement de Camunda": mantener BPMN pero adoptar built-in tasks como inspiration.

Filosofía fundamental¶

Dimensión	Camunda 8	Conductor
Workflow language	BPMN 2.0 (XML + visual)	JSON (proprietary DSL)
Standard	ISO BPMN 2.0	Custom
Target audience	Business + devs	Devs only
Visual modeling	First-class (Modeler)	Generated from JSON

Storage architecture¶

Aspecto	Camunda 8	Conductor
State store	RocksDB embedded	External (Dynomite, Redis, Postgres, MySQL)
Replication	Raft consensus nativo	DB-level replication
Snapshots	Chunk-based transfer	DB backup tools
Operational ownership	"Cluster" management	"Database" management

Trade-off: Camunda externaliza complejidad a su propio protocolo (Raft). Conductor externaliza a database operations. Net complejidad similar, pero el skillset operacional es diferente.

Task types built-in¶

Conductor tiene tasks tipo built-in que evitan necesidad de workers:

Conductor task type	Equivalente Camunda
`SIMPLE`	Service task + job worker
`HTTP`	Service task + connector HTTP
`DECISION` / `SWITCH`	Exclusive gateway + FEEL
`FORK_JOIN`	Parallel gateway
`DO_WHILE`	Multi-instance loop + condition
`SUB_WORKFLOW`	Call activity
`EVENT`	Message intermediate event
`HUMAN`	User task
`TERMINATE_WORKFLOW`	End event terminate

Camunda requiere connectors o workers para HTTP/REST. Conductor lo tiene built-in.

Workflow definition comparison¶

Camunda 8 — BPMN XML¶

<bpmn:process id="loan-approval" isExecutable="true">
  <bpmn:startEvent id="start" />
  <bpmn:sequenceFlow sourceRef="start" targetRef="check-credit" />

  <bpmn:serviceTask id="check-credit" name="Check Credit">
    <bpmn:extensionElements>
      <zeebe:taskDefinition type="credit-check" />
      <zeebe:ioMapping>
        <zeebe:input source="=applicantId" target="applicantId" />
      </zeebe:ioMapping>
    </bpmn:extensionElements>
  </bpmn:serviceTask>

  <bpmn:sequenceFlow sourceRef="check-credit" targetRef="approve" />
  <bpmn:endEvent id="approve" />
</bpmn:process>

Pros: visual, business-readable, standard. Cons: verbose, XML overhead, requires Modeler tool.

Conductor — JSON¶

{
  "name": "loan_approval",
  "version": 1,
  "tasks": [
    {
      "name": "check_credit",
      "taskReferenceName": "checkCredit",
      "type": "SIMPLE",
      "inputParameters": {
        "applicantId": "${workflow.input.applicantId}"
      }
    }
  ]
}

Pros: concise, dev-friendly, deployable as config. Cons: no visual, not standard, business analysts can't read.

Framework de evaluación oficial de Camunda¶

Del blog 2019, Camunda usa 10 criterios para auto-evaluación competitiva:

Workflow Definition (ISO standard?)
Visual Representation (1:1 model = code?)
Storage of Active State (embedded vs external)
Scalability (horizontal partitioning)
Fault Tolerance (replication, consensus)
Programming Languages (client SDKs)
Historic Workflow Data (export pipeline)
Kafka Integration (message correlation)
Deployment (cloud, on-prem, K8s)
Licensing (open source, AGPL implications)

Útil como lista de check para evaluar cualquier workflow engine — replicable para el MVP.

Performance estimado¶

Métrica	Camunda 8	Conductor (estimado)
TPS por broker/server	375 (Intuit benchmark)	~1,000+ (Netflix scale)
Latencia TP99	450ms (Intuit)	Similar range
Engine overhead	Single-digit ms por BPMN node	Lower (JSON parsing simpler than BPMN)

Conductor probablemente tiene mejor throughput puro porque: - JSON parsing < BPMN interpretation - Built-in tasks evitan worker network roundtrip - DB-direct writes simples vs Raft consensus

Pero Camunda tiene mejor visibility (BPMN visual) y fault tolerance (Raft).

Cuándo elegir cada uno¶

Camunda mejor cuando:¶

Compliance/audit requiere BPMN visual
Business analysts modelan procesos
Human tasks importantes (Tasklist)
DMN decision tables built-in
Multi-stakeholder workflows

Conductor mejor cuando:¶

Pure microservices coordination (dev-only)
Already operating Redis/Postgres/Dynomite
Workflow-as-config preferred over BPMN
Built-in HTTP/REST tasks save effort
Netflix-scale throughput requirements

Patterns prestables de Conductor para el MVP¶

Aunque el MVP es BPMN-centric, ideas de Conductor adoptables:

1. Built-in HTTP task (HOT)¶

En vez de requerir worker para cada REST call:

<bpmn:serviceTask id="callApi">
  <bpmn:extensionElements>
    <zeebe:taskDefinition type="builtin:http" />
    <zeebe:taskHeaders>
      <zeebe:header key="url" value="https://api.example.com/users/${id}" />
      <zeebe:header key="method" value="GET" />
      <zeebe:header key="responseVariable" value="userData" />
    </zeebe:taskHeaders>
  </bpmn:extensionElements>
</bpmn:serviceTask>

El engine MVP ejecuta el HTTP call directamente. Esto reduce 80% de los workers triviales.

2. Loop primitives mejoradas¶

Camunda usa multi-instance bodies. Es flexible pero complejo:

<bpmn:serviceTask id="processItems">
  <bpmn:multiInstanceLoopCharacteristics>
    <bpmn:loopCardinality>=count(items)</bpmn:loopCardinality>
    <bpmn:completionCondition>=approved &gt; 5</bpmn:completionCondition>
  </bpmn:multiInstanceLoopCharacteristics>
</bpmn:serviceTask>

Conductor's DO_WHILE es más directo. Considerar simplificar en MVP.

3. Workflow as configuration¶

JSON workflows en Conductor son deployable como cualquier config. Esto facilita GitOps. Camunda's BPMN también es deployable pero el tooling (Modeler) suele ser interactive, no CI-friendly.

Para MVP: asegurar que BPMN XML pueda ser fully declarative sin necesidad de UI tooling. Modeler como nice-to-have, no requirement.

Decisiones para el MVP¶

Aspecto	Decisión MVP	Justificación
Workflow language	BPMN 2.0	Requirement del MVP (drop-in Camunda)
Storage	PostgreSQL único	Más simple que RocksDB + ES
Built-in HTTP task	SÍ	Inspirado en Conductor, reduce workers triviales
Built-in decision task	NO	Exclusive gateway + FEEL es suficiente
Loop primitive	Multi-instance simple	No DO_WHILE separado
Visual modeler	Optional (Modeler integration)	XML completamente declarativo
Replication	NO en MVP (single-node)	Postgres replication para multi-region futuro

El MVP toma BPMN de Camunda + built-in tasks de Conductor + single storage de Temporal. Mejor de tres mundos.

Conclusión¶

Conductor representa el approach "JSON + DB + dev-first" a workflow orchestration. Tiene méritos pero diverge del target del MVP. Sin embargo, su feature de built-in HTTP/DECISION tasks es prestable y reduciría significativamente la fricción del MVP para casos comunes.

Camunda y Conductor son ambos válidos — la elección depende de quién es el usuario primario. Para el MVP que apunta a usuarios de Camunda, BPMN es non-negotiable, pero learn from Conductor sobre simplicidad operacional.