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 analysis/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 concepts/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 analysis/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