Sizing Benchmarks
Camunda 8 procesa nodos BPMN en single-digit milliseconds, con ~50ms de latencia end-to-end para service tasks remotos. La recomendación oficial es dimensionar para 20x la carga promedio. Un solo partition maneja ~1GB de payload; para >1M instancias con payloads de 4KB se necesitan 4-6 particiones.
Latencia de procesamiento¶
| Métrica | Valor | Contexto |
|---|---|---|
| Procesamiento por nodo BPMN | Single-digit ms | Engine interno (RocksDB + single-thread) |
| Latencia service task remoto | ~50 ms | Worker en misma cloud region |
| 4 service tasks end-to-end | ~200-250 ms | Overhead total del workflow |
Estos números reflejan el overhead del engine, no el tiempo de ejecución del worker (que depende de la lógica de negocio).
Reglas de dimensionamiento¶
Factor de seguridad¶
Camunda recomienda dimensionar para 20x la carga promedio. Esto cubre: - Picos de carga (días especiales, fin de mes) - Headroom para degradación gradual bajo carga - Margen para crecimiento orgánico
Ejemplo de cálculo¶
| Indicador | Número | Método |
|---|---|---|
| Instancias/año | 5,000,000 | Input de negocio |
| Pico diario | 150,000 | Input de negocio |
| Instancias/segundo (horario laboral) | 5.20 | ÷ (8×60×60) |
| Instancias/segundo (con 20x buffer) | 104.16 | × 20 |
Particiones¶
- 1 GB de payload por partición como máximo
- 1 millón de instancias × 4 KB cada una = 3.9 GB → mínimo 4 particiones
- Con replication factor 3: típicamente 6 particiones
- Cada partición es procesada por un single thread (ver concepts/partitioning)
Impacto de componentes¶
Optimize¶
Impacto significativo en throughput: - 25-50% reducción de throughput cuando Optimize está habilitado - 128 GB de Elasticsearch consumidos en <12 horas a 1 instancia/sec con 11KB payload y 30 días de retención
Esto refuerza la decisión del analysis/mvp-feature-matrix de clasificar Optimize como eliminable para el MVP.
Secondary Storage (RDBMS vs Elasticsearch)¶
| Backend | Throughput relativo | Madurez |
|---|---|---|
| Elasticsearch/OpenSearch | 100% (baseline) | Más maduro y benchmarked |
| RDBMS (PostgreSQL) | ~70% | Suficiente para la mayoría de casos |
Para un MVP basado en PostgreSQL, esperar ~70% del throughput de una instalación con ES. Esto es aceptable dado que el MVP no tendrá el overhead de Optimize ni exporters complejos.
Workers: throughput por configuración¶
| Configuración | Throughput estimado |
|---|---|
| 1 thread bloqueante, 100ms IO por job | ~10 jobs/sec |
| 10 threads bloqueantes, 100ms IO por job | ~100 jobs/sec |
| Reactivo (Node.js / WebFlux) | Bounded by IO, not threads |
| Batch activation (20-50 jobs/request) | Reduce overhead de polling |
| Job streaming vs polling | Menor latencia en clusters grandes |
Implicaciones para el MVP¶
- Single-digit ms por nodo es alcanzable con PostgreSQL si las queries están bien indexadas (RocksDB tiene ~µs; PG tiene ~ms — pero ambos son "single-digit ms")
- Una sola partición puede manejar cargas significativas — la regla de 1GB/partition sugiere que un MVP single-node con PostgreSQL puede manejar cientos de miles de instancias activas
- 20x factor: para un MVP, iniciar con 5x y escalar después
- Sin Optimize/ES: se elimina el 25-50% de overhead, el MVP puede ser más eficiente por instancia
- Workers reactivos: diseñar el SDK del worker con soporte async/non-blocking desde el inicio