Intuit Production Benchmarks
Intuit publicó en agosto 2024 los datos cuantitativos más completos sobre Camunda 8 en producción real: 22.74M procesos en 15h, 395 TPS sostenido (498 pico), 7,007 external tasks/sec pico, TP99 de 450ms. Configuración final: 15 brokers × 15 partitions (1:1), 8+ CPU y 8+ GB RAM por broker. Validan reglas operacionales y revelan problemas reales.
Tsunami test — números clave¶
Test sostenido de 15 horas:
| Métrica | Valor |
|---|---|
| Total procesos creados | 22,740,000 |
| TPS sostenido promedio | 395 |
| TPS pico | 498 |
| External task TPS máximo | 7,007 |
| External task TPS promedio | 2,815 |
| Total external tasks ejecutados | 114,000,000 |
| TP99 latency end-to-end | 450 ms |
| TP99 downstream latency | ~150 ms |
Comparación C7 vs C8¶
La mejora cuantificada de la migración:
| Métrica | Camunda 7 | Camunda 8 | Factor |
|---|---|---|---|
| Process creation TPS | 20 | 375 | 18.75x |
| TP99 external task latency | ~3.6s | ~250ms | 14.4x |
| Workflows creados en 10h sostenido | 577,000 | 15,000,000 | 26x |
Estos números validan empíricamente el ROI de la decisión arquitectónica de stream processing vs DB tradicional documentada en zeebe design philosophy.
Configuración final certificada¶
| Componente | Valor |
|---|---|
| Brokers | 15 |
| Partitions | 15 (mapping 1:1 con brokers) |
| CPU por broker | 8+ cores |
| RAM por broker | 8+ GB |
| EC2 IOPS provisionadas | 9,000 |
| EC2 throughput | 1,000 Mbps |
| Gateway pods | 7-8 |
| Storage type | GP3 (gen 3 SSD) |
Regla derivada para gateways: gateways = brokers / 2
Reglas operacionales validadas¶
1 partition por broker es óptimo¶
Intuit testeó múltiples configuraciones y concluyó que 1:1 partition/broker es lo mejor. Esto contradice la idea intuitiva de "más particiones = más throughput".
Razón probable (inferencia): cada partition es procesada por un single thread (ver stream processing). Múltiples particiones por broker compiten por los mismos cores. La proporción 1:1 maximiza utilización por broker.
Gateways: 200-250 TPS máximo cada uno¶
Esto da una regla concreta de capacity planning: - Si necesitas 1,000 TPS → 4-5 gateways - Si necesitas 5,000 TPS → 20-25 gateways
Streaming en clientes es esencial¶
El streaming de jobs (vs polling) habilitó la mayor parte de las mejoras: - 50% menos CPU del cluster Zeebe - 56% reducción en duración de process instances
GP3 > GP2 en EC2¶
Para reducir latencia de disco. Implicación para el MVP: usar SSDs NVMe locales o equivalentes en cloud.
Problemas reales encontrados¶
Variables > 100-150 KB → exports lentos¶
Variables grandes ralentizan significativamente los exports a Elasticsearch. La causa raíz: cada export es un documento entero serializado.
Implicación MVP: - Validar tamaño de variables en la API (hard limit, e.g., 100 KB) - Recomendar storage de payloads grandes en sistemas externos (ver service integration patterns)
Operate UI mostraba data stale bajo carga¶
El export pipeline es eventually consistent. Bajo alta carga, el lag entre engine y Operate aumenta.
Implicación MVP: documentar este lag como comportamiento esperado. Para queries que requieren consistency strong, ir directamente al engine state, no al store secundario.
100 duplicate events de 25M procesos¶
At-least-once delivery semantics produjeron 100 eventos duplicados en condiciones extremas. Root cause aún bajo investigación al momento del post.
Implicación MVP: - Workers DEBEN ser idempotentes — no es opcional - Documentar at-least-once explícitamente en el SDK - Considerar correlation IDs estables para dedup en workers
TP99 degradaba después de 75-90 minutos¶
Bajo carga sostenida, TP99 empezaba a degradar a los 75-90 min, requiriendo intervención.
Implicación MVP: - Monitoring continuo con alertas en TP99 - Auto-tuning o circuit breakers - Tests de carga sostenida (no solo bursts)
Workflow característico del test¶
| Característica | Valor |
|---|---|
| External tasks por proceso | 7 (totalmente async) |
| Process variables por instancia | ~75 |
| Variables como maps | Varias |
Este perfil es representativo de uso real: workflows con varios pasos async, muchas variables, algunas estructuradas.
Targets sugeridos para el MVP¶
Basado en Intuit, escalado para un MVP single-node:
| Métrica | Intuit | MVP Target | Razón |
|---|---|---|---|
| Process creation TPS | 375 (C8) | 100 | Single-node, sin distribución |
| External task TPS | 7,007 | 500-1,000 | Limitado por gateway sin partitioning |
| TP99 end-to-end | 450 ms | < 1 segundo | Margen para SQL vs RocksDB |
| Workflows en 10h | 15M | 2-5M | Suficiente para 99% de casos |
| Variables max size | 100 KB | 100 KB hard limit | Mismo enforcement |
| Memoria | 8+ GB | 4 GB | Single-node más eficiente |
Lecciones clave consolidadas¶
- Stream processing pays off: 18-26x mejora vs DB tradicional en producción real
- 1:1 partition/broker es óptimo: para single-node MVP, 1 thread principal es correcto
- Streaming jobs > polling: implementar desde el inicio
- Variables grandes son problema universal: enforce limit, no solo documentar
- At-least-once duplicates ocurren bajo carga extrema: idempotency es non-negotiable
- Sustained load degradation es real: tests deben incluir 4+ horas, no solo bursts
- Gateway: 200-250 TPS: capacity planning rule of thumb