1. Resumen ejecutivo

Problema. Los canales de AndesRetail (e-commerce propio y marketplaces) hablan directo con cada sistema. Cada consulta de stock o precio golpea en línea al ERP (Enterprise Resource Planning, el sistema central de gestión, dueño de catálogo y precios) y al WMS (Warehouse Management System, el sistema de bodega, dueño del stock físico). Cada canal coordina a su manera la creación de órdenes contra el OMS (Order Management System, el sistema de órdenes) y nadie es dueño del stock que se puede vender. El resultado son caídas en promociones, sobreventa, órdenes pagadas sin confirmar y ninguna forma de seguir una orden de punta a punta.

Solución propuesta.

1. Una capa de interoperabilidad entre los canales y los sistemas, con APIs estándar y versionadas para stock, precios, órdenes y notificaciones.
2. Las consultas de stock y precio se responden desde un modelo de lectura propio, alimentado por eventos. La carga sobre ERP y WMS deja de depender del tráfico de los canales.
3. La capa se hace dueña del stock vendible: reserva antes de aceptar una orden, con vencimiento.
4. Crear orden es una sola saga orquestada (una secuencia de pasos con su forma de deshacerlos), con idempotencia y compensaciones: lo que se puede deshacer se deshace, lo que ya se cobró se termina.
5. Cada sistema queda detrás de un adaptador que traduce y lo protege con límites de concurrencia. Sumar un sistema es sumar un adaptador.
6. Seguridad uniforme: OAuth2 y OIDC (OpenID Connect), los estándares de autorización e identidad, con permisos por scope, políticas y cuotas por partner, y cifrado mutuo entre servicios. La capa nunca ve datos de tarjeta.
7. Trazabilidad de punta a punta con un identificador de correlación en peticiones, eventos y auditoría.
8. Es síncrono solo lo que la capa puede responder con sus propios datos; lo que depende de un tercero es asíncrono.
9. Migración gradual, canal por canal, con vuelta atrás en cada paso. MVP (minimum viable product: la primera entrega útil en producción) en 4 a 6 semanas con un marketplace piloto.
10. Cada requisito no funcional tiene una prueba automática definida para que la arquitectura no se degrade con el tiempo: unas ya son compuerta del pipeline y el resto se ejecuta aparte y entra a él según el roadmap.

Beneficio de negocio. Vender en promociones sin caídas; no prometer lo que no hay; saber siempre en qué va una orden; sumar un marketplace o cambiar un sistema en semanas y no en meses; y un solo lugar donde aplicar seguridad y cumplimiento.

Lo que cuesta. Más piezas que operar, consistencia eventual declarada en las lecturas, un crear orden que responde "aceptada" y no el resultado final, y un equipo de plataforma que hoy no existe. Las lecturas ya están medidas en el demo (sección 6.8): con el pico 10x, el AS-IS llega al timeout y el TO-BE responde en milisegundos sin cargar al legado. En órdenes, un reintento con la misma llave no duplica (0 de más en 20, contra 20 de 20 duplicadas en el AS-IS), y el pago rechazado, el webhook perdido y el OMS caído se resuelven sin intervención.