Prueba técnica de arquitectura · Andrés Ayala · 17/11/2026
El problema
Cada canal habla directo con cada sistema
Ocho de las doce integraciones son conexiones directas de los canales a los sistemas, en línea, con su propio formato y su propia autenticación.
Nadie es dueño del stock que se puede vender.
Integraciones punto a punto frágiles
Inconsistencias de stock, precio y estado
Caídas en picos y promociones
Ninguna traza de punta a punta
Seguridad distinta en cada integración
2
La tesis
Una capa responde con sus propios datos
LecturasStock y precio salen de un modelo propio alimentado por eventos.
Dueño del stockLa capa reserva antes de aceptar una orden.
Una sagaCrear orden es un solo flujo, con idempotencia y compensaciones.
Solo los adaptadores hablan con ERP, WMS, OMS y CRM.
3
Antes y después
Del contacto directo a un solo punto de entrada
AS-IS: integraciones punto a puntoTO-BE: capa de interoperabilidad
4
Arquitectura de alto nivel
Gateway delgado, servicios por dueño del dato, Kafka entre ellos
Sin REST entre servicios de dominio: la única llamada síncrona interna es gRPC de order-service a inventory-service.
5
Decisión 1 de 3
Las lecturas salen de un modelo propio
Qué se decideStock y precio se responden desde Redis, alimentado por eventos. El legado no está en la ruta de la consulta.
Lo que cuestaEl dato puede estar desactualizado unos segundos. Se declara en cada respuesta (asOf y stale) y se mide. Más piezas en la ruta de alimentación.
ADR-005 y ADR-007. La decisión de prometer una unidad no usa este dato: usa la reserva.
6
Decisión 2 de 3
La capa es dueña del stock vendible
Qué se decideHoy nadie lo es. La capa reserva con vencimiento antes de aceptar la orden, para no sobrevender.
Lo que cuestaEs la única excepción a que la capa no posea datos de negocio. La garantía es total entre canales que pasan por ella y parcial frente a ventas que no pasan (tiendas físicas, canales sin migrar): se cubre con colchón y conciliación.
ADR-003.
7
Decisión 3 de 3
Crear orden es una saga orquestada
Qué se decideUn orquestador en order-service: reserva, cobro como pivote, registro en el OMS.
Lo que cuestaorder-service conoce a los demás participantes. Responde 202 aceptada, no el resultado final. La recuperación es código propio.
1 · ReservargRPC a inventory-service
2 · Aceptar202 al canal
3 · CobrarAsíncrono y pivote del flujo
4 · ConfirmarReserva confirmada
5 · RegistrarEn el OMS, por un adaptador
ADR-004. Antes del cobro todo se deshace; después, todo se reintenta. Secuencia completa en la sección 4.4 del entregable.
8
Evidencia medida · pico 10x de consultas
El AS-IS llega al timeout; el TO-BE no se mueve
AS-IS en la nube
5.000 ms
p95 de stock y precio: el timeout del canal. Error: 100%.
TO-BE en la nube
12 ms
p95 de stock (precio 10,3 ms). Error: 0%.
docs/comparativo-as-is-to-be.md, "La misma medición en la nube": EKS en us-east-1, AS-IS el 14/11/2026 y TO-BE el 15/11/2026.
9
Evidencia medida · el legado queda protegido
Menos llamadas al legado, y las órdenes no se duplican
AS-IS
TO-BE
Llamadas por segundo al ERP en el pico
200
0,9, igual que en la base
Con el ERP caído, ¿responde el precio?
No (0,03%)
Sí, 100%
Orden creada dos veces por reintento
20 de 20
0 de más en 20
Misma fuente, tabla de la nube. El pico del AS-IS supera lo que el ERP alcanza a atender (66,6 por segundo).
10
Seguridad
Una identidad, permisos por ruta, nada de tarjetas
OAuth2 y OIDC con un solo proveedor de identidad
Scope por ruta; ninguna ruta sin scope
Cuotas y políticas por partner y canal
Cifrado mutuo entre servicios
Secretos gestionados, nunca en el repositorio
La capa no ve datos de tarjeta; el dato personal vive cifrado en un solo servicio
Sección 5 del entregable.
11
Operación
Se ve cada orden de punta a punta
Un correlationId en peticiones, eventos y auditoría
Métricas, trazas y logs JSON desde la plataforma
Alertas de frescura, de colas de fallidos y de pagos
Degradación preparada: con el legado caído, las lecturas siguen y marcan el dato como desactualizado
Runbook de falla de stock o precio
Disponibilidad objetivo de 99.9% con tres zonas
Secciones 6 y 7 del entregable.
12
Roadmap
Migración por estrangulamiento, con vuelta atrás
MVP, 4 a 6 semanas
Un marketplace piloto
Lecturas y órdenes completas
Seguridad completa desde el día uno
A 3 meses
Todos los marketplaces
E-commerce leyendo por la capa
Adaptador del CRM
A 6 meses
Órdenes del e-commerce por la capa
Devoluciones y cancelaciones
Recuperación ante desastres probada
Sección 8 del entregable. Cada paso: sombra, canario, corte y retiro de la integración vieja.
13
En vivo
Lo que se muestra ahora
Comprar en la tiendaCon la consola al lado, viendo los eventos de la orden.
Rechazar un pagoLa compensación: orden cancelada, reserva liberada, stock de vuelta.
Apagar el ERPY seguir vendiendo.
Lanzar el pico 10xCon las llamadas al legado planas.
andesretail.commonitor.andesretail.com (acceso por correo)control.andesretail.com (acceso por correo)
