Saltar a contenido

ADR-003: Single-node MVP, escalar incrementalmente

  • Status: Accepted
  • Date: 2026-05-14
  • Tags: scaling, infrastructure, mvp

Context and Problem Statement

Camunda 8 nace distribuido — multi-broker con Raft, partitioning, gossip. ¿El MVP debe seguir este pattern desde día 1, o empezar simple y escalar reactivamente?

Decision Drivers

  • Time-to-market (single-node tiene ~10x menos código)
  • 99% de use cases reales son < 100 TPS sostenido
  • Premature scaling = wasted investment
  • Operational complexity escalates exponentially
  • Postgres puede scale verticalmente bastante alto

Considered Options

  1. Single-node MVP, escalar por fases (Phase 0 → 1 → 2 → ...)
  2. Multi-node from day 1 (como Camunda)
  3. Cloud-native multi-region desde inicio
  4. Serverless (cada workflow es lambda)

Decision Outcome

Chosen option: Single-node MVP, escalar por fases porque: - Time-to-MVP es prioridad #1 - 99% de casos reales no requieren > Phase 1 - Postgres en single-node maneja cómodamente 200 TPS - Scaling decisions deben tomarse con métricas reales, no especulación - Each phase es cambio incremental de infra (no rewrite)

Positive Consequences

  • ~6 meses al MVP funcional vs ~2 años para distributed
  • Operational complexity manejable en Phase 0 (1 dev part-time)
  • Cost mínimo inicial (1 VM + 1 Postgres)
  • Validación de product-market fit antes de invertir en scaling
  • Aprendizaje del workload real informa la arquitectura

Negative Consequences

  • SLA limited a 99% en Phase 0 (failover manual)
  • No HA out-of-the-box (requiere Phase 1)
  • Single point of failure inicial
  • Si product explota rápidamente, scaling reactive puede ser stressful

Pros and Cons of the Options

Single-node MVP, escalar por fases

Pros: - Fastest time-to-MVP - Validar product antes de scaling investment - Métricas reales informan decisiones - Patterns correctos desde día 1 permiten scaling sin rewrite - Cost mínimo inicial

Cons: - 99% SLA inicial (no HA) - Single point of failure - Requires Phase 1 antes de production-critical use

Multi-node from day 1 (Camunda style)

Pros: - Production-ready desde lanzamiento - HA built-in - Scaling headroom

Cons: - ~2 años más de investment - Complexity prematura - 90% de features de scaling no usadas inicialmente - Decisiones de scaling sin data real

Cloud-native multi-region

Pros: - Geo-resilient desde inicio - Latency global baja

Cons: - Cost prohibitivo para MVP - Complexity extrema (conflict resolution, etc.) - Premature optimization para 99%+ de use cases

Serverless (lambda por workflow)

Pros: - Auto-scaling - Pay-per-use

Cons: - Workflow engines requieren state continuity (mal fit para stateless) - Lambda cold starts arruinan TP99 - Vendor lock-in (AWS Lambda específico)

Triggers de transición entre fases

Ver analysis/scaling-strategy-postgres para detalle, resumen:

Fase Trigger para próxima
0 — Single-node SLA > 99% requerido
1 — HA replicas Zero-downtime deploys necesarios
2 — Active-active engines Write TPS > 1000
3 — Tenant sharding Cross-tenant queries frecuentes
4 — Citus Multi-region requerido
5 — Geo-distribuido Active-active multi-region

Patterns que se mantienen en TODAS las fases

Critical: arquitectar el código del MVP con abstracciones correctas desde día 0 para que cada fase sea incremental, no rewrite:

  • Command sourcing pattern
  • RecordProcessor interface (ver concepts/journal-and-stream-platform)
  • ProcessingResultBuilder declarativo
  • Replay determinism (ver ADR-019)
  • Idempotent workers (ver ADR-007)
  • Post-commit task isolation