Log — Camunda Platform Architecture Analysis¶

Historial append-only de ingests y lints. Formato: ## YYYY-MM-DD HH:MM — tipo.

2026-05-14 — init¶

Proyecto creado desde plantillas.

2026-05-14 — ingest masivo (7 sources → 38 páginas wiki)¶

Sources ingeridos (7): 1. raw/monorepo-structure-analysis.md — estructura Maven, 50+ módulos, dependencias, LOC 2. raw/zeebe-engine-core-analysis.md — StreamProcessor, RocksDB, Raft, key encoding, record format 3. raw/bpmn-dmn-engine-analysis.md — pipeline BPMN 5 pasos, 24 processors, 12 behaviors, DMN/FEEL 4. raw/resilience-patterns-analysis.md — timers, retries, incidents, compensation, signals, backpressure 5. raw/exporters-webapps-analysis.md — exporter SPI, Operate, Tasklist, Optimize, Connectors SDK 6. raw/identity-security-analysis.md — OIDC multi-IdP, authorization 20 resource types, multi-tenancy 7. raw/official-docs-architecture.md — documentación oficial de arquitectura Camunda 8

Páginas creadas (38):

Sources: 7 páginas índice en wiki/sources/
Entidades: 7 páginas en wiki/entities/ (zeebe-broker, zeebe-gateway, operate, tasklist, optimize, identity, connectors)
Conceptos: 20 páginas en wiki/concepts/ (stream-processing, command-sourcing, partitioning, raft-consensus, rocksdb-state-store, bpmn-execution-model, bpmn-element-processors, dmn-integration, grpc-api, job-worker-pattern, exporter-system, message-correlation, timer-system, retry-backoff, incident-management, backpressure, authentication-flow, authorization-model, multi-tenancy, search-infrastructure, monorepo-modulos)
Análisis: 4 páginas en wiki/analysis/ (c4-architecture-diagrams, trade-offs-arquitectonicos, mvp-feature-matrix, blueprint-plataforma-simplificada)

Gaps detectados: 6 items (ver gaps.md)

2026-05-14 — deepen iter 1: engine processors deep analysis¶

Source ingerido: raw/engine-processors-deep-analysis.md — análisis de EngineProcessors.java, BpmnProcessors.java, ProcessInstanceCreationCreateProcessor, DeploymentCreateProcessor

Páginas creadas (4): - wiki/sources/engine-processors-deep-analysis.md — source index - wiki/concepts/engine-processor-registry.md — registro central de ~80 processors - wiki/concepts/deployment-pipeline.md — flujo completo de deployment - wiki/concepts/process-instance-creation.md — flujo de creación de process instances

Gap resuelto: Source candidato alta — análisis detallado de processors individuales

2026-05-14 — deepen iter 2: best practices docs (sizing, errors, integration)¶

Source ingerido: raw/best-practices-docs.md — 6 artículos de docs.camunda.io/best-practices

Páginas creadas (4): - wiki/sources/best-practices-docs.md — source index - wiki/analysis/sizing-benchmarks.md — datos cuantitativos de rendimiento y sizing - wiki/analysis/error-handling-patterns.md — flujo end-to-end de errores (retries, BPMN errors, incidents, sagas) - wiki/analysis/service-integration-patterns.md — patrones BPMN de integración, workers, data handling

Gaps resueltos: Source candidato alta (best practices docs) + Gap alta (error handling patterns) + parcialmente Gap alta (performance benchmarks)

2026-05-14 — deepen iter 3: microbenchmarks (JMH) + PostgreSQL monitoring queries¶

Source ingerido: raw/microbenchmarks-and-rdbms-perf.md — análisis de microbenchmarks/ y docs/.../rdbms/benchmarking.md

Páginas creadas (3): - wiki/sources/microbenchmarks-and-rdbms-perf.md — source index - wiki/concepts/microbenchmark-methodology.md — JMH config, métricas, profilers, GC comparisons - wiki/concepts/postgres-monitoring.md — queries oficiales de PostgreSQL (sessions, statements, tables, indexes, WAL)

Hallazgo importante: el monorepo NO tiene benchmarks de end-to-end throughput de procesos — esos viven en un load-tester separado no público. El módulo microbenchmarks/ solo cubre MessagePack y caching. Reusar instancias en deserialización reduce allocations 25x.

Gap resuelto: Source candidato media (zeebe benchmarks) — descubrió que están en microbenchmarks/ y load-tester separado

2026-05-14 — deepen iter 4: engineering blog posts (Intuit production benchmarks)¶

Source ingerido: raw/engineering-blog-posts.md — 4 posts: State of Zeebe Performance (Feb 2025), Origin Story (Jul 2019), Dynamic Scaling podcast (Mar 2024), Intuit case study (Aug 2024)

Páginas creadas (3): - wiki/sources/engineering-blog-posts.md — source index - wiki/analysis/intuit-production-benchmarks.md — datos cuantitativos reales: 22.74M procesos en 15h, 395 TPS sostenido, TP99 450ms, infraestructura 15×15 - wiki/analysis/zeebe-design-philosophy.md — decisión arquitectónica decisiva (stream processing > DB), timeline 4 años R&D, alternativas rechazadas

Hallazgos clave: Intuit es la única fuente pública con datos cuantitativos completos. 1 partition por broker es óptimo (regla validada). Gateway max ~250 TPS. Variables > 100KB ralentizan exports. Camunda 8 es 18-26x más rápido que C7.

Gap resuelto: Source candidato media (engineering blog) — los datos cuantitativos están en el caso Intuit

2026-05-14 — deepen iter 5: engine test patterns (replay determinism, property-based)¶

Source ingerido: raw/engine-test-patterns.md — análisis del framework de tests del engine Zeebe

Páginas creadas (4): - wiki/sources/engine-test-patterns.md — source index - wiki/concepts/replay-determinism.md — garantía contractual processing=replay, excepciones documentadas - wiki/concepts/property-based-testing.md — random BPMN models y paths, invariantes universales - wiki/concepts/test-infrastructure.md — EngineRule, RecordingExporter, fluent BPMN builder, time control

Hallazgo importante: ContinuouslyReplayTest corre dos engines compartiendo el log y compara state column-by-column. DEFAULT y MIGRATIONS_STATE se excluyen explícitamente. Property tests usan 6 procesos × 30 paths por default. El directorio incident/ tiene 20 archivos de tests confirmando que incidents ocurren en al menos 18 scenarios distintos.

Gap resuelto: Source candidato media (zeebe tests) + ayuda parcialmente al gap baja "Zeebe test framework"

2026-05-14 — deepen iter 6: variable scoping (expansión de stub)¶

Source ingerido: raw/variable-behavior-source.md — análisis de VariableBehavior.java

Páginas creadas/actualizadas (2): - wiki/sources/variable-behavior-source.md — source index - wiki/concepts/variable-scoping.md — EXPANDIDA de stub (32 líneas) a página completa (~250 líneas) con algoritmo de propagación, optimizaciones, schema SQL, API sugerida

Hallazgos clave: VariableBehavior tiene 3 métodos (mergeLocalDocument, mergeDocument, setLocalVariable). mergeDocument implementa shadowing bottom-to-top con un loop while subiendo por scope_chain. Optimization: skip no-op events si valor no cambia. Triggers conditional events después de cada mutación.

Gap resuelto: Gap media — "Variable scoping detallado"

2026-05-14 — deepen iter 7: connector SDK deep dive¶

Source ingerido: raw/connector-sdk-deep-dive.md — análisis de camunda/connectors repo

Páginas creadas (2): - wiki/sources/connector-sdk-deep-dive.md — source index - wiki/concepts/connector-sdk-architecture.md — OutboundConnectorFunction (1 método), InboundConnectorExecutable (lifecycle async), bindVariables magic, secret providers chain, element templates

Hallazgos clave: Outbound es trivial (1 método execute()), pero inbound es complejo (lifecycle, async required, correlation strategies). context.bindVariables(Class) hace 3 cosas en una llamada: deserialize + replace secrets + validate. CorrelationFailureHandlingStrategy tiene dos modos: ForwardErrorToUpstream o Ignore. Element template generator produce JSON para Web Modeler desde anotaciones.

Gap resuelto: Gap media — "Connector SDK extensibilidad"

2026-05-14 — deepen iter 8: SWIM membership protocol (cluster topology)¶

Source ingerido: raw/cluster-topology-swim.md — análisis de zeebe/atomix/cluster/ module

Páginas creadas (2): - wiki/sources/cluster-topology-swim.md — source index - wiki/concepts/swim-membership-protocol.md — SWIM protocol completo con parámetros oficiales, failure detection flow, indirect probing, disputes

Hallazgos clave: Camunda usa SWIM con defaults: probe 1s, timeout 2s, 3 suspect probes, 10s failure timeout, gossip 250ms con fanout 2, sync cada 10s. Indirect probing previene falsos positivos. Threading single-threaded consistente con el resto del engine. Eventos: MEMBER_ADDED, MEMBER_REMOVED, METADATA_CHANGED, REACHABILITY_CHANGED.

Gap resuelto: Gap media — "Cluster topology management"

2026-05-14 — deepen iter 9: process instance migration¶

Source ingerido: raw/process-migration-source.md — análisis de ProcessInstanceMigrationMigrateProcessor

Páginas creadas (2): - wiki/sources/process-migration-source.md — source index - wiki/concepts/process-instance-migration.md — mecanismo completo, 4 behaviors, 18 element types soportados, precondiciones, alternativas

Hallazgos clave: Migration es feature compleja: 4 behaviors especializados (CatchEvents, Jobs, UserTasks, SequenceFlows), 18 element types soportados, solo 4 intermediate catch event types (message/timer/signal/conditional). Usa BFS iterativo con ArrayDeque (no recursión) para evitar stackoverflow. 10+ precondiciones de validación. Para MVP: SKIP — alternativa simple es dejar v1 terminar mientras v2 sirve nuevas instancias.

Gap resuelto: Gap media — "Process instance migration"

2026-05-14 — deepen iter 10: CONTRIBUTING.md (development conventions)¶

Source ingerido: raw/contributing-guide.md — análisis de CONTRIBUTING.md

Páginas creadas (2): - wiki/sources/contributing-guide.md — source index - wiki/concepts/development-conventions.md — severity heuristic, build, code style, PR workflow

Hallazgo clave: Severity heuristic ("¿Hubo data loss?" → CRITICAL) revela prioridades operacionales: Data integrity > Availability > Exporting. Algunos módulos están en JDK 8 (cliente y protocol) para compatibilidad. El módulo identity será renombrado a admin. Review emoji code (👍❓❌🔧💭) distingue blockers de suggestions.

Gap resuelto: Source candidato baja — CONTRIBUTING.md

2026-05-14 — deepen iter 11: cluster internal protocols (deployment distribution + snapshot transfer)¶

Source ingerido: raw/deployment-distribution-and-snapshot-transfer.md — análisis combinado de los dos protocolos cluster-internal

Páginas creadas (2): - wiki/sources/deployment-distribution-and-snapshot-transfer.md — source index - wiki/concepts/cluster-internal-protocols.md — ambos protocolos combinados con patterns reusables

Hallazgos clave: Deployment distribution usa ACK-based completion tracking + DeploymentRedistributionScheduler para eventual consistency. @ExcludeAuthorizationCheck marker distingue internal vs external commands. Snapshot transfer es chunk-based con CRC32C checksum por chunk, "no retry built-in" (cliente decide policy), SnapshotReservation pattern previene GC durante transfer. Para single-node MVP: ambos protocolos SKIP — PostgreSQL replication maneja todo.

Gaps resueltos: Gap baja "Deployment distribution protocol" + Gap baja "Snapshot transfer protocol"

2026-05-14 — lint completo + discover (post-11 ingests)¶

Lint check resultados: - 0 unresolved wikilinks ✓ - 0 páginas huérfanas (todas referenciadas) ✓ - Total: 71 páginas wiki, 19 raw sources, 56+ commits - Página más central: concepts/stream-processing (18 backlinks) - Source más referenciado: sources/zeebe-engine-core-analysis (16 backlinks)

Cobertura de preguntas guía: - Las 15 preguntas guía del CLAUDE.md tienen respuestas distribuidas en el wiki - Triangulables via index.md + categorías

Páginas under-covered (todas son source indexes — esperado): las páginas en wiki/sources/ son intencionalmente cortas (resúmenes + links a derivadas)

Discover (H1-H5) ejecutado, nuevos candidatos generados en gaps.md: - 3 sources media (atomix, stream-platform, journal — citation chasing H1) - 3 comparisons baja (Temporal, Conductor, Argo — related work H5) - 1 concept baja (SBE — under-covered H3)

Conclusión: wiki en estado saludable. Listo para más iteraciones de /deepen si el usuario lo desea, o para servir como blueprint operacional del MVP.

2026-05-14 — deepen iter 12: Camunda vs Temporal comparison¶

Source ingerido: raw/camunda-vs-temporal-comparison.md — web research + Temporal community forum

Páginas creadas (2): - wiki/sources/camunda-vs-temporal-comparison.md — source index - wiki/comparisons/camunda-8-vs-temporal.md — primera página en categoría comparisons

Hallazgos clave: - Camunda: BPMN + RocksDB + exporters (eventually consistent visibility) - Temporal: Code + DB pluggable + direct queries (real-time visibility) - Temporal tiene in-flight versioning vía GetVersion() markers - Temporal tiene multi-region nativo; Camunda no - Para MVP: tomar BPMN de Camunda + single state store con direct queries de Temporal - Eliminar el doble-store (RocksDB + ES) reduce 50% complejidad operacional sin perder funcionalidad

Gap resuelto: Source candidato baja "Comparación Camunda 8 vs Temporal"

2026-05-14 — fin de la sesión de deepen¶

12 iteraciones completas en esta sesión. El wiki cubre exhaustivamente la arquitectura interna de Camunda 8/Zeebe, sus decisiones de diseño, patterns reusables, y trade-offs. Provee blueprint operacional para construir MVP simplificado. Estado final:

72 páginas wiki
20 raw sources
0 unresolved wikilinks
0 páginas huérfanas
5 gaps abiertos (todos baja prioridad: atomix detail, stream-platform, journal, comparisons con Conductor/Argo, SBE)

2026-05-14 — deepen iter 13: Camunda vs Conductor comparison¶

Source ingerido: raw/camunda-vs-conductor-comparison.md — análisis de evaluación oficial Camunda + posts de comparación

Páginas creadas (2): - wiki/sources/camunda-vs-conductor-comparison.md — source index - wiki/comparisons/camunda-8-vs-conductor.md

Hallazgos clave: Conductor usa JSON DSL en vez de BPMN, delega replication a la DB (Dynomite/Redis/Postgres) en vez de Raft, tiene built-in tasks (HTTP, DECISION, DO_WHILE, SUB_WORKFLOW) que evitan necesidad de workers. Camunda publica un framework de evaluación de 10 criterios (workflow def, visual rep, state storage, scalability, fault tolerance, languages, history, Kafka, deployment, license) — replicable para evaluar cualquier engine. Patterns prestables: built-in HTTP task reduce 80% workers triviales.

Gap resuelto: Source candidato baja "Comparación Camunda 8 vs Conductor"

2026-05-14 — deepen iter 14: Simple Binary Encoding (SBE)¶

Source ingerido: raw/sbe-overview.md — SBE specification + Real Logic docs

Páginas creadas (2): - wiki/sources/sbe-overview.md — source index - wiki/concepts/sbe-serialization.md — SBE technical details, 6 design principles, comparación con alternativas, decisión MVP

Hallazgos clave: SBE da encode/decode en 10-50 nanosegundos (vs 100-500 ns Protobuf, 1-10 μs JSON). Las 6 design principles (copy-free, native types, allocation-free, streaming, word-aligned, backward compat) son aplicables a cualquier sistema high-performance, no solo SBE. Para MVP: NO usar SBE — JSON/Protobuf son suficientes. Las design principles sí aplican (especialmente object pooling = allocation-free).

Gap resuelto: Concept baja "SBE (Simple Binary Encoding)"

2026-05-14 — deepen iter 15: Camunda vs Argo Workflows¶

Source ingerido: raw/camunda-vs-argo-comparison.md — análisis comparativo

Páginas creadas (2): - wiki/sources/camunda-vs-argo-comparison.md — source index - wiki/comparisons/camunda-8-vs-argo.md

Hallazgo clave: Camunda y Argo Workflows NO son competidores reales — atacan problemas diferentes. Camunda: business workflows con human tasks y BPMN. Argo: containerized pipelines K8s-native para CI/CD, ML, ETL. Son complementarios: pueden coexistir en una organización (Camunda para business, Argo para technical). El MVP NO debe replicar Argo, pero sí asegurar deployment K8s-native.

Gap resuelto: Comparación Camunda 8 vs Argo Workflows. Cierra el "competitive landscape" del MVP.

2026-05-14 — deepen iter 16: Journal & Stream Platform (foundation layers)¶

Source ingerido: raw/journal-and-stream-platform.md — análisis combinado de los módulos foundation del engine

Páginas creadas (2): - wiki/sources/journal-and-stream-platform.md — source index - wiki/concepts/journal-and-stream-platform.md

Hallazgos clave: - Camunda separa el engine en 4 capas (engine → stream-platform → logstreams → journal). Cada una testeable independientemente. - Journal usa doble sequencing: index (Raft-level monotonic) + asqn (Application Sequence Number con gaps OK). - Stream-platform's RecordProcessor interface separa init/accepts/replay/process — crítico para replay determinism. - ProcessingResultBuilder es declarative (no imperative writes) — permite atomic transactions de state + log. - Post-commit tasks isolan side effects (HTTP, async ops) de state mutations atomic. - Para MVP basado en Postgres: módulos se reemplazan pero patterns son aplicables directamente.

Gaps resueltos: Sources candidatos media "stream-platform" + "journal"

2026-05-14 — deepen iter 17: Atomix fork analysis (consensus heritage)¶

Source ingerido: raw/atomix-fork-analysis.md — análisis del README del módulo atomix + estructura del codebase

Páginas creadas (2): - wiki/sources/atomix-fork-analysis.md — source index - wiki/concepts/atomix-fork-lessons.md — historia del fork, pros/cons, recomendaciones MVP

Hallazgos clave del README oficial de Camunda: - Camunda mantiene un hard fork de Atomix (Raft + SWIM + transport) - Upstream pivotó a Go, PRs Java no se mergeaban - Costos documentados: build complexity, snapshot version inestable, release coupling - Solución: mergear todo el fork al monorepo de Zeebe - Removieron ~50% del codebase original (no necesario) - Listeners pattern (RaftRoleChangeListener, RaftCommitListener, etc.) es excelente design replicable

Lección general aplicada al MVP: NO forkear protocolos de consensus. Opciones: skip consensus (single-node + Postgres), usar library existente (hashicorp/raft, etcd/raft), o external coordination (Consul, etcd). Fork solo si tienes 2+ engineers full-time dedicados — Camunda's own README documenta el costo real.

Gap resuelto: Source candidato media "atomix details"

2026-05-14 — FIN de la sesión exhaustiva de deepen¶

Estadísticas finales: 17 iteraciones de /deepen completadas en esta sesión. TODOS los gaps en el backlog original (alta, media, baja) están resueltos. Lint pasa: 0 unresolved, 0 huerfanos.

Páginas totales: ~80 wiki + 22 raw sources Categorías cubiertas: sources (21), concepts (~40), entities (7), analysis (10), comparisons (3)

El wiki ahora cubre exhaustivamente: - Arquitectura interna de Zeebe (engine, processors, behaviors, state) - Foundation modules (journal, stream-platform, atomix fork) - Resilience patterns (timers, retries, incidents, backpressure) - Resilience infrastructure (Raft, SWIM, snapshot transfer) - BPMN execution (24 element processors, variable scoping) - DMN integration - API surface (gRPC + REST + REST search) - Job worker pattern - Connectors SDK (outbound + inbound) - Multi-tenancy, authentication, authorization - Exporters y search infrastructure - Webapps (Operate, Tasklist, Optimize) - Testing methodology (replay determinism, property-based) - Performance benchmarks (Intuit production data) - Development conventions - Competitive landscape (Temporal, Conductor, Argo) - MVP blueprint con SQL schemas y trade-offs documentados

El wiki es un blueprint operacional completo para construir una plataforma simplificada que pueda ser drop-in replacement de Camunda 8.

2026-05-14 — Q&A: estrategia de escalamiento Postgres¶

Pregunta del usuario: ¿Cómo seria la estrategia de escalamiento desde el MVP hacia una plataforma que requiera la escalabilidad y replicacion necesaria con postgres?

Página creada: wiki/analysis/scaling-strategy-postgres.md

Roadmap de 6 fases: - Fase 0 — MVP single-node (100-200 TPS, 99% availability) - Fase 1 — HA con read replicas (Patroni + streaming repl, 99.9%) - Fase 2 — Active-active engines (leader election via PG advisory lock o Consul, 99.95%) - Fase 3 — Tenant sharding (smart router app-level, 5K-10K TPS) - Fase 4 — Citus (transparent horizontal scaling, 10K-100K TPS) - Fase 5 — Geo-distribución (logical replication, per-region primary) - Fase 6 — Multi-master (extremo, considerar CockroachDB/Yugabyte)

Insight clave: Postgres ecosystem (Patroni, pgBackRest, WAL-G, Citus) cubre gratis lo que Camunda construyó manualmente (Raft fork, snapshot transfer, SWIM). Trade-off: failover ~30s (Patroni) vs <1s (Raft) — aceptable para 99% de casos a cambio de mucha menos complejidad.

2026-05-15 — review + discover exhaustivo¶

Estado del wiki: - 24 sources / 25 raw — 1 orphan detectado (raw/exporter-spi-docs.md sin source page ni referencias). Marcado en gaps.md como health issue. - 44 concepts, 7 entities, 23 analysis, 3 comparisons, 26 ADRs → ~127 páginas - 0 wikilinks rotos, 0 huérfanos - Backlog gaps.md: vacío (todos los items resueltos)

Heurísticas corridas: - H1 (citation chasing): SWIM paper Das/Gupta/Motivala 2002 + Aeron (Real Logic, mismo equipo SBE) — 2 candidatos - H2 (author tracking): no hay entity_type: person pages, pero Bernd Ruecker (co-founder Camunda) emerge como autor central via prolific blog → 2 posts candidatos - H3 (under-covered): 3 ADRs cortos pero intencionalmente concisos; sin candidatos urgentes - H4 (preguntas guía): las 15 preguntas tienen cobertura — sin candidatos - H5 (related work): 7 candidatos validados — DBOS, Restate, Flowable, Kogito, AWS Step Functions, Cadence, Inngest, LittleHorse

Candidatos únicos tras dedup: 12 (3 ya existentes en wiki saltados: Temporal, Conductor, Argo)

Agregados a gaps.md "Sources candidatos": 5 alta + 4 media + 3 baja

Top 3 por relevancia para MVP: 1. DBOS (docs.dbos.dev/architecture) — durable workflows sobre Postgres puro, stack más cercano al MVP 2. Flowable (github.com/flowable/flowable-engine) — engine BPMN con abstract persistence layer (Postgres-friendly) 3. Bernd Ruecker (cheat sheet + embedded vs remote) — autoridad arquitectónica Camunda, choreography vs orchestration es gap actual

2026-05-15 — deepen iter 18: SWIM paper (Das/Gupta/Motivala 2002)¶

Source ingerido: raw/swim-paper-das-gupta-motivala-2002.md — extracción completa del paper canónico (DSN'02). H1 citation chasing del primer alta candidato.

Páginas creadas (5): - wiki/sources/swim-paper-das-gupta-motivala-2002.md — source index - wiki/concepts/failure-detector-formal-properties.md — Strong Completeness, Speed, Accuracy, Network Load (Chandra-Toueg) + FLP impossibility - wiki/concepts/infection-style-dissemination.md — Bailey 1975 epidemic model; coverage N - N^(-(2λ-2)) después de λ·log(N) rounds; comparación con LISTEN/NOTIFY para MVP - wiki/concepts/incarnation-numbers.md — Suspect/Alive/Confirm preference rules; analogía AODV; ejemplo end-to-end de resolución de flapping - wiki/analysis/swim-paper-vs-camunda-defaults.md — comparación directa: 4 brechas detectadas

Páginas actualizadas (2): - wiki/concepts/swim-membership-protocol.md — agregado source paper + sección "Cross-refs (paper original + brechas)" - wiki/index.md — 5 nuevas entradas (1 source + 3 conceptos + 1 analysis)

Hallazgos clave:

FLP impossibility (1985) es el por qué del Suspicion mechanism: en redes asíncronas no se puede tener accuracy + completeness simultáneas. Camunda elige completeness (no perder muertes) + minimizar (no eliminar) false positives.
Cuatro brechas Camunda vs paper:
Brecha 1: probeTimeout=2s > probeInterval=1s viola el constraint del paper "T' >= 3 × RTT". Hipótesis: probe loop async overlapping en scalecube. Verificar.
Brecha 2: round-robin probe target selection (mecanismo del §4.3 del paper que garantiza Time Bounded Completeness 2N · T') NO expuesto en config Camunda. Riesgo teórico de detection time unbounded para clusters muy grandes. scalecube usa random según docs públicos.
Brecha 3: piggyback count λ · log(N) opaco en config — bloquea validación de coverage promise.
Brecha 4: suspicion timeout fijo (10s) vs paper que escala con N (λ · log(N) × T'). Trade-off operacional aceptable hasta N≈30 brokers.
Incarnation numbers = pattern general "version monotónico controlado por el sujeto del state": AODV destination sequence numbers, MVCC timestamps, vector clocks, CRDT counters, DNS SOA serial son todos instances del mismo pattern.
Para MVP < 10 nodos sobre Postgres: SWIM custom es overkill. Una tabla cluster_members + pg_stat_activity + cron de cleanup logra 30s detection con ~200 LOC vs ~5000 LOC SWIM. Migrar a infection-style solo si > 50 nodos o geo-distribuido.
Bailey 1975 epidemic model es independiente del dominio: aplica a cache invalidation gossip, configuration propagation, blockchain transaction propagation. Pattern reusable más allá de membership.

Gap resuelto: Sources candidatos alta — SWIM paper (citation chasing de concepts/swim-membership-protocol)

Gaps nuevos detectados (3 media + 1 baja): ver gaps.md sección "Gaps nuevos (detectados durante deepen 2026-05-15)" — todos requieren inspección de source de scalecube/Atomix o experimentación empírica.

2026-05-14 — Sprint: 20 deep-dives operacionales (M1-M4 readiness)¶

Iteración masiva de 20 análisis adicionales para cubrir lo necesario entre "blueprint aprobado" e "implementación productiva". Foco en SDK, ops, semántica BPMN precisa, distribution strategy, compliance.

Páginas creadas (20):

Developer experience (4): - wiki/analysis/worker-sdk-go-design.md — API del SDK Go: JobHandler, BPMN errors, OTel built-in, testing utils, ~600 LOC docs - wiki/analysis/cli-tool-design.md — wf CLI kubectl-style: deploy/start/inspect/incident/cluster/replay, shell completion, output formats - wiki/analysis/grpc-vs-rest-tradeoffs.md — Decisión: REST default + gRPC opcional para streaming workers (M2+) - wiki/analysis/api-versioning-strategy.md — REST URL path + SDK semver + BPMN namespace + wire protocol, deprecation 12-24 meses

BPMN semántica precisa (4): - wiki/analysis/bpmn-coverage-matrix.md — Matriz 80+ elementos por fase: M1 80%, M2 92%, M3 98%, M4 100% - wiki/concepts/compensation-and-bpmn-errors.md — BPMN errors (boundary), incidents (uncaught), compensation (LIFO + variable snapshot), reglas precisas - wiki/concepts/subprocess-and-call-activity.md — Embedded vs call activity: scope, variables, lifecycle, error/comp boundaries, performance - wiki/analysis/process-modification-runtime.md — Cancel/activate/move/setvar en instancias en vuelo, replay determinism, audit, bulk modify

Reliability y testing (4): - wiki/analysis/worker-reliability-patterns.md — Retry + circuit breaker + bulkhead + timeout + idempotency + poison + graceful degradation. Checklist pre-prod - wiki/analysis/process-testing-framework.md — Unit (Go puro) + integration (engine in-memory) + scenario (testcontainers) + load. AdvanceTime, assertions fluentes - wiki/analysis/idempotency-and-deduplication.md — Dedup 6 layers: API ingress (Idempotency-Key), command log, job lease, external calls, message bus, audit - wiki/analysis/webhook-delivery-reliability.md — Outbox pattern, retry exponencial (max 7), HMAC signature, rate limit per endpoint, DLQ, SSRF protection

Operations (4): - wiki/analysis/schema-migration-strategy.md — Postgres zero-downtime: expand/migrate/contract, CONCURRENTLY, NOT VALID, partitioning, Citus considerations - wiki/analysis/disaster-recovery-runbook.md — RPO/RTO targets por fase, 7 scenarios (node/DB/AZ/region/corruption/ransomware), runbooks ejecutables, chaos drills - wiki/analysis/performance-testing-methodology.md — 6 workloads (W1-W6), k6 scripts, baseline en CI, capacity calculator, soak 24h - wiki/analysis/kubernetes-operator-design.md — CRDs WorkflowCluster/Tenant/Process/Worker, reconciliation, Patroni integration, GitOps, multi-cluster mesh

Distribution y strategy (4): - wiki/analysis/multi-region-active-active.md — 3 modelos (active-passive, sharded per-tenant, truly distributed). Recomendación Modelo B (per-tenant) opcional M5+ - wiki/analysis/open-source-license-strategy.md — Apache 2.0 vs BSL vs AGPL vs SSPL. Recomendación: Apache 2.0 + open core. DCO sign-off, trademark - wiki/analysis/adoption-playbook-90-days.md — Plan ejecutivo equipo nuevo: días 0-14 discovery, 15-30 foundations, 31-60 first prod, 61-90 expansion. Hitos verificables - wiki/analysis/compliance-roadmap.md — SOC 2 + GDPR + HIPAA: cobertura por phase, controls, subject request API, BAA, hash-chain audit log

Insights consolidados:

DX como prioridad arquitectónica: Hello-world < 30 min, SDK ergonomic (zero magic), CLI scriptable, testing en 3 niveles. Sin DX, adopción muere.
At-least-once everywhere → dedup obligatorio: idempotency en 6 layers; sin esto, retry causa data corruption. Outbox pattern crítico.
BPMN semántica precisa importa: ambigüedad en compensation, subprocess scoping, boundary errors → bugs en producción. Documentar tan preciso como un standard.
Operations day-2 antes que features day-1: schema migrations zero-downtime, DR drills, capacity planning, observability — más valor que el 90% de features fancy.
Multi-region complejidad >> beneficio: solo Modelo B (per-tenant sharding) tiene ROI claro. Modelo C (Spanner-class) excluido del roadmap.
Compliance es proceso, no checkbox: SOC 2 Type II requiere 6+ meses ops evidence. Empezar Phase 1, audit en M6.

Total después del sprint: 151 wiki pages, 26 ADRs (sin cambios), análisis cubre M1 (3-6m) hasta M5+ (24+m).

2026-05-14 — MVP Implementation Plan hyper-detallado para Claude Code¶

Página creada: wiki/analysis/mvp-implementation-plan-detailed.md (~1500 líneas)

Plan ejecutable de 230 tasks atómicas distribuidas en 9 fases (P0 foundations → P8 production) cubriendo 26 semanas de implementación del MVP. Optimizado para alimentar a Claude Code que spawneará agents paralelos por wave del DAG.

Componentes del plan:

Scope MVP M1: 28 elementos BPMN, REST API 25 endpoints, Worker SDK Go, CLI 12 comandos, Tasklist + Process Inspector, OIDC + RBAC 3 roles, target 100 inst/s + p99 < 1s.
Stack técnico fijado: Go 1.22 + libs concretas (pgx/v5, chi, cobra, cel-go, OTel), TS 5.4 + React 18 + Vite + Playwright, Postgres 16, golang-migrate, testcontainers.
Estructura monorepo: layout completo cmd/ + internal/ + pkg/ + webapp/ + migrations/ + deploy/ con module boundaries enforced.
TDD obligatorio: disciplina RED-GREEN-REFACTOR por commit, naming convention Test<Subject>_<Scenario>_<Outcome>, 4 categorías mínimo (happy/edge/error/invariant), coverage thresholds por módulo (95% engine, 90% API, etc.), mutation testing target > 75% kill rate.
Determinismo obligatorio: reloj inyectable, RNG con seed explícito, IDs determinísticos (partition+position), sort estable, goleak.VerifyTestMain, property-based tests (rapid) sobre replay determinism.
Static analysis stack: golangci-lint config completa (30+ linters), gosec, govulncheck, semgrep (p/owasp-top-ten + p/golang), SonarQube con quality gates custom (coverage 90% new code, A ratings), trivy + syft + grype + cosign para supply chain, ESLint + sonarjs + security para TS, sqlfluff para SQL, go-licenses para compliance.
CI/CD pipeline: 8 jobs (lint < 3min, unit-tests, integration-tests con testcontainers, security, SonarQube quality gate, scenario-tests, load nightly, container-build con trivy + cosign).
Task catalog: 230 tasks en formato YAML-like parseable. Cada task: id, phase, estimate (max 2d), dependencies, files_create, acceptance_criteria, test_files, tdd_steps, static_analysis. Ejemplos completos para P0-P3, summary para P4-P8.
Quality gates por fase: coverage thresholds + SonarQube rating + security tools + performance targets, escalando rigurosidad por fase.
Definition of Done: 13 checks obligatorios (tests primero visibles en git history, golangci-lint zero, gosec clean, govulncheck clean, SonarQube pass, goleak clean, determinism reproducer, godoc, code review, no breaking changes).
Agent orchestration: wave-based execution (8 waves), spawn template con prompts estructurados, isolation via worktree, parallel safety, failure handling (BLOCKED_BY_DEP / BUG_IN_DEP / SPEC_AMBIGUOUS / TIMEOUT / QUALITY_GATE_FAIL), auto-retry max 3 con context expandido.
Continuous metrics: dashboard ASCII con progreso, velocity tracking, quality stats.
Risk register: 8 riesgos identificados con likelihood/impact/mitigation.

Apéndices: Makefile completo, plantilla de PR (con TDD evidence en commits), tools cheat sheet.

Insight clave: el plan asume agents paralelos por wave (5-15 simultáneos), cada uno produciendo PR con TDD evidence en commit history. Quality gates automáticos = merge sin revisión humana si todos verdes. Esto requiere disciplina extrema en determinismo y idempotency tests para evitar flakiness.