Debate 02 — Crítica Técnica Consolidada de ConTodo ERP

Rol del autor. Partner de Tecnología y Arquitectura en revisión crítica nivel Big Four. Mi función no es validar lo escrito por los siete agentes técnicos, sino estresar sus supuestos, cazar contradicciones entre documentos (donde nadie tuvo visibilidad del otro), exponer trade-offs que se declararon resueltos pero no lo están, y cuantificar deuda técnica latente. La conclusión de un agente individual puede ser correcta en su silo y aun así romper el sistema cuando se ensambla con los demás. Aquí reviso el ensamble.

Disclaimer anti-overclaiming. Los siete documentos son, individualmente, de calidad alta y poco común para una etapa pre-MVP. Esta crítica es deliberadamente adversarial: asume que el lector ya leyó las virtudes y necesita oír lo que falla. Ninguna observación invalida el proyecto; varias sí condicionan su viabilidad económica a escala.

0. Veredicto ejecutivo

Bottom line: la arquitectura es vendible y técnicamente seria, pero está escrita por siete especialistas que no negociaron entre sí. El riesgo número uno no es técnico sino de gobierno: no existe un contrato de arquitectura único que reconcilie las decisiones contradictorias antes de escribir la primera línea de código. Este documento es el insumo para esa reconciliación.

1. Contradicciones inter-documento (hallazgo crítico)

Cuando siete agentes escriben en paralelo sin un ADR maestro, divergen. Estas divergencias no son matices de estilo: son decisiones de infraestructura incompatibles que costarían reescritura si se descubren en implementación.

Conclusión de la sección: 8 contradicciones, 5 de severidad Alta. Antes de codificar se necesita una sesión de reconciliación de ADRs que produzca un único documento maestro de decisiones vinculantes. Sin esto, cada equipo construye sobre supuestos del vecino que no se cumplen.

2. Coherencia multi-tenant vs costos AWS vs seguridad (el triángulo central)

El producto vive o muere en el equilibrio de tres fuerzas que se tensionan entre sí. Los agentes optimizaron cada vértice por separado.

2.1 El triángulo

2.2 Coherencia de la decisión Shared Schema + RLS

Lo que está bien. Los tres documentos que tocan tenancy (07, 08, 13) convergen en Shared Schema + RLS + Silo-on-demand. Es la decisión correcta para un SaaS de PYMEs y está bien justificada (Salesforce/Shopify/Zoho como precedente, economía de escala, onboarding instantáneo). La defensa en profundidad (Pundit → default_scope → RLS) es de manual.

Lo que no se resolvió:

1. Costo de RLS bajo carga real. RLS añade un predicado a cada query. En tablas particionadas y gigantes (kardex, asientos), el planner de PostgreSQL puede degradar si las policies no usan índices alineados con current_setting. Ningún documento midió el overhead de RLS ni definió un benchmark. A 5.000 tenants en una db.r6g.4xlarge, esto puede ser la diferencia entre p95 = 250 ms y p95 = 1.5 s.

2. SET LOCAL y connection pooling. Rails (08) usa SET LOCAL app.current_company_id dentro de una transacción. Pero DevOps (10) impone RDS Proxy / PgBouncer desde 100 clientes. PgBouncer en modo transaction puede romper SET que no sea SET LOCAL, y RDS Proxy multiplexa conexiones de forma que una variable de sesión mal scopeada filtra contexto entre tenants. Este es el bug de seguridad más peligroso y más probable de toda la arquitectura, y ningún documento lo aborda. El uso de SET LOCAL (transaccional) lo mitiga, pero exige que toda query corra dentro de una transacción explícita — algo que Rails NO hace por defecto en lecturas. Es deuda técnica de seguridad latente.

3. Particionado por tenant_id choca con power-law. Architect (07, S3) admite que el 5% de tenants genera el 50% de la carga. Particionar por LIST/HASH(tenant_id) con esa distribución crea particiones desbalanceadas: una partición con un tenant gigante y otras casi vacías. El particionado por tenant_id no resuelve noisy-neighbor para el tenant pesado dentro de su propia partición. La mitigación real para ese 5% es promoverlos a Silo, pero el disparador no está definido.

2.3 Costos AWS — auditoría del modelo de DevOps

El modelo de costos (10, §9) es el artefacto más concreto y por eso el más auditable. Mis objeciones:

Costo total realista a 5.000 tenants: no ~US$ 20.600/mes sino, con BI + IA completos, US$ 35.000–60.000/mes. El "costo por cliente ~US$ 4,1" se convierte en US$ 7–12. Sigue siendo un margen sano si el pricing es US$ 25–40/cliente, pero el margen >80% es optimista; el realista es 65–75% una vez que se costean los diferenciadores (IA, BI) que el equipo de producto va a vender.

Recomendación: el modelo de costos debe ser un solo artefacto consolidado que incluya las líneas de IA y BI, no tres modelos parciales. El P&L del agente de Finanzas debe usar el ajustado, no el optimista.

2.4 Seguridad — el pilar más fuerte, con un hueco

Ciberseguridad (13) es el mejor documento del set: RBAC+ABAC, SoD codificado, audit log con hash chain + WORM, STRIDE, OWASP, readiness SOC2/ISO. Hueco operativo crítico: el equipo de seguridad declarado es "0 dedicados → 1 Security Engineer" (S5) para sostener SOC 2 Type II, ISO 27001, pentest anual, bug bounty, DPA con subprocesadores, flujos ARCO, DLP y respuesta a incidentes. Eso es trabajo de un equipo de 3–4, no de 1. La ambición de compliance está sub-presupuestada en personas, no en controles. Es coherente con el doc de Finanzas solo si se contempla outsourcing (vCISO + plataforma Vanta/Drata), lo cual hay que hacer explícito.

3. Escalabilidad de Rails a 5.000 tenants

3.1 ¿Es defendible? Sí, con condiciones

Rails como modular monolith con YJIT, Fargate stateless y RDS Proxy escala horizontalmente sin techo en compute. El cuello de botella es siempre la base de datos única, y aquí los documentos son honestos pero difieren las soluciones a un "futuro" sin dueño:

3.2 El verdadero límite: el "noisy migration"

El argumento estrella de Shared Schema vs Separate Schema es "una sola migración" (07, §3.3). Cierto. Pero a escala, esa única migración corre sobre tablas compartidas de cientos de millones de filas. Un add_index o un backfill bloquea o consume IOPS que afectan a los 5.000 tenants simultáneamente. Separate Schema reparte el dolor; Shared Schema lo concentra. El doc vende la simplicidad sin cuantificar que la migración pasa de "trivial" a "evento de mantenimiento planificado con riesgo para todos". Deuda técnica: falta una estrategia de migraciones por lotes con pt-online-schema-change/gh-ost-equivalente para Postgres (ej. pg-osc) desde el día 1.

3.3 Outbox relay como single point of contention

Rails (08) centraliza TODO en el outbox: eventos de dominio, webhooks, y (implícitamente) alimenta a BI. Data (12) en cambio usa CDC/Debezium que lee el WAL, NO el outbox. Hay dos mecanismos de captura de cambios compitiendo: outbox (08) y CDC (12). Si BI usa CDC, el "outbox como changelog para BI" (08, O1) es redundante. Si BI usa outbox, Debezium/Kafka sobra. Nadie eligió. Esto es a la vez una contradicción (C4/C6) y un riesgo de escalabilidad: dos pipelines de eventos doblan la carga sobre el WAL y el costo operativo.

4. Trade-offs declarados como resueltos que NO lo están

5. Riesgos técnicos consolidados (cross-cutting)

Riesgos que ningún documento individual ve porque emergen del ensamble:

6. Deuda técnica latente (que se contrae el día 1 si no se actúa)

1. Ausencia de un ADR maestro. Siete documentos, cero contrato unificado. La primera deuda es de gobierno, no de código.
2. Tipo y nombre de tenant_id sin fijar (C2, C3). Cambiarlo después es una migración global.
3. Pooler + RLS sin probar juntos (RT1). Si se descubre tras 500 tenants, es incidente de seguridad reportable.
4. Estrategia de migración a escala inexistente. Se asume "rails db:migrate" eterno.
5. Pipeline de eventos no decidido (outbox vs CDC). Construir ambos es deuda doble.
6. Backup/restore por tenant. Shared Schema lo hace difícil; la Ley 29733 lo exige. Se menciona pero no se diseña.
7. Promoción shared→silo sin diseño de migración de datos (T8).
8. Observabilidad de IA y costos por tenant (medidor de tokens) está en IA (11) pero no integrado al CloudWatch/X-Ray de DevOps (10).
9. Contrato OpenAPI como fuente de verdad (09) depende de que Rails (08) lo publique disciplinadamente; ningún doc define quién es dueño del spec ni el proceso de breaking changes.

7. Oportunidades técnicas (lo que el ensamble habilita y nadie capitalizó del todo)

8. Recomendaciones consolidadas y priorizadas

8.1 Bloqueantes antes de escribir código (Semana 0–2)

1. Sesión de reconciliación de ADRs. Producir un único ADR-MASTER.md que resuelva C1–C8. Decisiones vinculantes: región (una), nombre y tipo de tenant_id, bus de eventos (uno), stack de BI (fasing real), modelo de costos consolidado.
2. Resolver RT1 (pooler + RLS). Diseñar y probar el mecanismo de SET LOCAL a través de RDS Proxy/PgBouncer. Sin esto validado, la promesa de aislamiento es papel. Es el riesgo de seguridad más alto del proyecto.
3. Fijar tipo de tenant_id (recomendación: BIGINT interno + UUID público) y nombre canónico (recomendación: tenant_id, no company_id).

8.2 Antes del MVP (Mes 1–3)

4. Reducir superficie operativa del MVP. Diferir MSK, Debezium, Redshift, Cube y Llama-VPC. MVP de BI = batch nocturno con dbt + DuckDB/S3 (como el propio Data admite en su fasing). MVP de IA = Bedrock managed (Claude/Haiku), sin self-host GPU.
5. Cola critical en On-Demand, no Spot. Política explícita en Terraform.
6. Estrategia de migración a escala (expand/contract + pg-osc + runbook) desde la primera tabla.
7. Modelo de costos consolidado que incluya IA y BI, entregado al agente de Finanzas para recalcular margen (esperar 65–75%, no >80%).

8.3 Antes de 500–1.000 tenants (Mes 6–12)

8. ADR de sharding con métrica gatillo y dueño (RACI). No "a futuro".
9. Diseño de promoción shared→silo incluyendo migración de datos con cero downtime.
10. Contratar SRE dedicado y formalizar seguridad (vCISO + Vanta/Drata) — el equipo de 4–6 no sostiene el stack a esa escala.
11. Decidir CDC sí/no según necesidad real de latencia BI (<5 min). Si el batch satisface, no introducir Kafka jamás.

8.4 Tabla RACI mínima propuesta

9. Conclusión

Los siete documentos técnicos de ConTodo son, individualmente, de calidad superior y reflejan criterio senior real: la decisión de tenancy está bien razonada, la seguridad es el pilar más sólido, y el modelo de datos dimensional es de manual. El proyecto es técnicamente viable y comercialmente diferenciable.

El problema no está en las piezas sino en el ensamble. Escritos en paralelo sin un contrato maestro, los agentes contradicen entre sí la región AWS, el tipo de tenancy enterprise, el nombre y tipo de la clave de tenant, el bus de eventos y el stack de BI. Más grave: el modelo de costos omite IA y BI —precisamente los diferenciadores que el negocio va a vender—, lo que infla el margen prometido de >80% a un realista 65–75% y subestima el costo a 5.000 tenants en un factor de ~2–3x. Y existe un riesgo de aislamiento cross-tenant no resuelto en la intersección de RDS Proxy y las variables de sesión de RLS que, de materializarse en producción, sería un evento de extinción de marca para un ERP contable.

La recomendación central es una sola: antes de escribir código, sentar a los siete agentes en una sesión de reconciliación que produzca un ADR maestro vinculante, valide el binomio pooler+RLS, y consolide un único modelo de costos. La arquitectura está a una semana de gobierno de ser excelente; sin ese gobierno, está a varios meses de reescritura de descubrir sus contradicciones en producción.