Capa de interoperabilidad · Prueba técnica de arquitectura

Comparativo AS-IS frente a TO-BE

Estado: 10/11/2026. Es la pieza que muestra la diferencia. Alimenta el resumen ejecutivo y la apertura de la sección 3.

En una frase

Antes, cada canal hablaba directo con cada sistema y coordinaba su propia cadena. Ahora, los canales hablan con una capa que responde con sus propios datos, orquesta una sola saga y es la única que toca los sistemas existentes.

Estructura

AS-IS TO-BE
Diagrama as-is/01-sistemas-e-integraciones.md to-be/01-arquitectura.md
Conexiones de canales a sistemas 8 directas (integraciones 1 a 8) 0: todo pasa por la capa
Quién conoce el formato de cada sistema Todos sus consumidores Solo su adaptador
Identidad Una por integración Un proveedor de identidad, un token, scopes
Dueño del stock vendible Nadie inventory-service
Dueño del flujo de crear orden Cada canal order-service

Comportamiento

Flujo AS-IS TO-BE
A. Crear orden as-is/02-flujo-crear-orden.md: cadena síncrona sin compensación to-be/04-saga-crear-orden.md: saga orquestada, reserva, idempotencia
B. Consulta en promo as-is/03-flujo-consulta-en-promo.md: cada lectura golpea al legado to-be/05-modelo-de-lectura.md: lectura desde modelo propio

Problema por problema

Problema del PDF Causa en el AS-IS Mecanismo en el TO-BE Cómo se mide
Integraciones punto a punto frágiles 12 conexiones directas; coordinación repetida en cada canal Adaptador por sistema, modelo canónico, contratos versionados, saga única Canales con acceso directo al legado: 0. Tiempo para sumar un sistema nuevo
Inconsistencias en stock, precios y estado Sin dueño del stock vendible; lote nocturno; webhooks perdidos Reserva atómica antes de aceptar; modelo de lectura por eventos con frescura medida; outbox y deduplicación Órdenes rechazadas por sobreventa después de aceptadas: 0. Frescura p95. Órdenes atascadas
Incidentes en picos Las lecturas de los canales llegan en línea al ERP y al WMS Lecturas desde Redis; cuotas por partner; adaptadores con límite de concurrencia p95 bajo 300 ms a 10x. Llamadas al legado planas durante el pico
Poca trazabilidad y auditoría Ningún identificador cruza los sistemas correlationId y traza W3C en HTTP, gRPC y eventos; registro de auditoría inmutable Porcentaje de órdenes con traza completa de punta a punta
Seguridad inconsistente Una autenticación por integración; sin permisos por canal OAuth2 y OIDC central, scopes, política por partner, mTLS interno, secretos gestionados Rutas sin scope: 0. Credenciales directas al legado en manos de canales: 0

Requisitos no funcionales

Requisito AS-IS TO-BE
Disponibilidad 99.9% Atada al ERP, al WMS y al enlace on-prem La ruta de las APIs no depende de ellos
p95 menor a 300 ms Depende del ERP bajo carga Presupuesto interno de 55 ms
Multi-tenant No existe Cuotas y políticas por partner
Evolución Cada sistema nuevo toca a todos sus consumidores Un adaptador nuevo
PII y pago Repartidos sin control uniforme PII solo en un servicio y cifrada; la capa no ve tarjetas

Evidencia del demo

El mismo escenario de carga contra los dos lados (plataforma/03-playground-de-escenarios.md). La tabla se llena con las corridas reales; no se inventan cifras.

Medida AS-IS (mocks directos) TO-BE (por la capa)
p95 de stock y precio en tráfico base Stock 128 ms, precio 196 ms Stock 3 ms, precio 3 ms
p95 de stock y precio en pico 10x 5.001 ms los dos: el timeout del canal 1,6 ms los dos
Tasa de error en pico 10x 100% en stock y en precio 0% en stock y en precio
Llamadas por segundo al ERP en pico 10x 200 (20 en la base: crecen 10x con el tráfico); el ERP alcanza a atender 67 0,9 (0,9 en la base: planas; es el sondeo del erp-adapter, no depende de las consultas). Igual en el WMS
ERP lento (3 s de latencia) Precio con p95 de 5.001 ms (el timeout) y 99,6% de error p95 de precio 1,9 ms y 0% de error; el circuit breaker del erp-adapter abre y las llamadas al ERP bajan de 0,9 a 0,1 por segundo
Con el ERP caído, ¿responde stock y precio? Precio no (0,03% de respuestas correctas); stock sí, porque viene del WMS. Con el WMS caído, stock no Sí, los dos: 100% de respuestas correctas durante 180 s de caída, y lo mismo con el WMS caído. El precio sale stale: true pasado el umbral (a los 41,5 s, con un umbral de prueba de 45 s en lugar de 30 minutos)
Frescura p95: del cambio en el legado a la respuesta de la API No aplica: cada consulta lee el legado en línea Precio 1,2 s (objetivo 60 s); stock 1,2 s (objetivo 10 s); 10 cambios de cada uno
Orden creada dos veces por reintento Sí: 20 de 20 órdenes reintentadas tras timeout quedaron duplicadas (40 en el OMS) No: 20 de 20 primeros envíos vencidos por timeout del canal y reintentados con la misma Idempotency-Key dieron 20 órdenes en la capa y 20 en el OMS, 0 de más (tests/load/results/to-be/orden-duplicada-20261111T195659Z.json)
Compras durante un despliegue (reinicio de los servicios) No aplica: el AS-IS no tiene capa que desplegar; cada canal llega al legado Una compra cada 3 s mientras se reinician los cuatro servicios Java: 0 de 94 sin 202 en tres corridas seguidas, y 0 de 85 con el agente montado por el chart (antes del calentamiento antes de readyz, 2 de 29 con 503). Kind con 4 CPU y el agente de OpenTelemetry, tests/load/results/to-be/arranque-en-frio-20261115T204237Z.json y siguientes
Un partner excede su cuota (escenario 6) No aplica: no hay cuotas por partner; cada canal llega al legado sin límite propio Bronze a 5 veces su cuota (100 lecturas por segundo): recibe 20,1 por segundo y el resto en 429 RATE_LIMITED con Retry-After (79,9%). Gold al mismo tiempo: 0 errores y p95 de 6,6 ms (8,2 ms sin el exceso). Malla en kind, tests/load/results/to-be/escenario-6-cuota-20261114T202635Z.json

Cifras de un solo equipo de desarrollo con Docker Desktop, no de producción: sin red entre zonas, sin cifrado en tránsito, sin Cloudflare ni malla. Lo que se compara es el comportamiento a la misma escala y en el mismo equipo: con el pico 10x el AS-IS llega al timeout y el TO-BE no se mueve. La latencia absoluta del TO-BE (milisegundos) no es la de producción; su presupuesto está en to-be/05-modelo-de-lectura.md.

Condiciones de la medición AS-IS (10/11/2026): k6 2.3.0 en Docker Desktop sobre un Ryzen 9 7950X3D con 32 hilos, máquina compartida con contenedores de otros proyectos; base 20 y pico 200 consultas por segundo con llegada abierta; timeout del canal de 5 s; perillas por defecto del diseño. Detalle, archivos y lectura en tests/load/results/as-is/README.md.

Condiciones de la medición TO-BE (11/11/2026): el mismo equipo, k6 y escenarios; las consultas pasan por el gateway con el token de un partner del realm (partner-mkp-caribe o partner-mkp-nuevo) y llegan a pricing-service e inventory-service, alimentados por erp-adapter y wms-adapter desde los mismos mocks con sus perillas por defecto. Valores del diseño en los componentes, salvo el umbral de stale del precio (45 s para la prueba de la caída). Corrida de make f3-e2e y escenarios 2 y 3 aparte; detalle, archivos y lectura en tests/load/results/to-be/README.md.

Flujo de órdenes (11/11/2026, make f4-e2e, todas las piezas reales detrás del borde): pruebas de comportamiento en el TO-BE, sin columna AS-IS porque el AS-IS no tiene saga ni compensación. En verde los escenarios 4 (pago rechazado: orden cancelada, reserva liberada, stock de vuelta) y 5 (webhook duplicado: un solo cambio; perdido: la consulta a la pasarela lo resuelve al minuto), el OMS caído (la orden se registra una vez al volver), F9, F7, F6 y F8; y 100 pedidos simultáneos por la última unidad dan una venta (make f4-reservas-test). Detalle en deploy/compose/f4-integracion/README.md y en la sección 6.8 del entregable.

Escenario 6 (14/11/2026, make mesh-kind-test): la malla en vivo en un clúster kind del mismo equipo, con Istio 1.31.4, mTLS estricto y k6 dentro del clúster contra el gateway de entrada. La misma prueba comprueba que una llamada directa a un servicio, saltando el gateway, se rechaza (sin sidecar, la conexión se corta; dentro de la malla, 403) y que el circuit breaker de la malla expulsa al ERP lento y falla en el acto. Condiciones y lectura en tests/load/results/to-be/README.md; la prueba y lo que corrigió en tests/e2e/mesh/README.md.

La misma medición en la nube

El AS-IS se repitió en AWS el 14/11/2026: simuladores en EKS (us-east-1, dos nodos m7i-flex.xlarge) y k6 dentro del clúster, con los mismos scripts y perillas. Condiciones, archivos y lectura en tests/load/results/as-is-nube/README.md. El TO-BE se midió el 15/11/2026 en el mismo clúster, con la capa completa, la malla aplicada y Kafka en un pod (ADR-028); k6 entra por el gateway de entrada de Istio con el token real de un partner (sin Cloudflare ni el NLB). Condiciones, archivos y lectura en tests/load/results/to-be-nube/README.md.

Medida AS-IS en la nube TO-BE en la nube
p95 de stock y precio en tráfico base Stock 129 ms, precio 196 ms Stock 10,7 ms, precio 8,6 ms
p95 de stock y precio en pico 10x 5.000 ms los dos: el timeout del canal Stock 12,0 ms, precio 10,3 ms
Tasa de error en pico 10x 100% en stock y en precio 0%
Llamadas por segundo al ERP en pico 10x 200 (20 en la base); el ERP atiende 66,6 0,9, igual que en la base
ERP lento (3 s de latencia) Precio con p95 de 5.000 ms y 99,5% de error Precio con p95 de 8,6 ms y 0% de error
Con el ERP caído, ¿responde stock y precio? Precio no (0,03%); stock sí. Con el WMS caído, stock no (0,03%) Los dos responden el 100% con el ERP caído y con el WMS caído
Orden creada dos veces por reintento Sí: 20 de 20 (40 en el OMS) No: 0 de más en 20
Un partner excede su cuota (escenario 6) No aplica Bronze a 5 veces su cuota: 20,2 aceptadas por segundo y 80% de 429 con Retry-After; gold sin errores, p95 13,2 ms. La primera corrida no aplicó la cuota (servicio de cuotas sin usuario en Redis); causa y arreglo en el README de la corrida

El AS-IS da en la nube lo mismo que en el equipo de desarrollo: su límite no es la máquina, es que cada consulta llega en línea al legado. El TO-BE en la nube responde en milisegundos con el legado lento o caído, porque la consulta ya no llega al legado; sus p95 son mayores que en local (tabla de arriba) por el TLS del gateway de entrada, el mTLS de la malla y la red entre nodos.

Lo que el TO-BE cuesta

Un comparativo honesto incluye lo que se paga: