8. Plan de implementación (roadmap)
Conclusión. Migración por estrangulamiento: la capa crece alrededor de las integraciones existentes y las reemplaza una por una, primero lo que más duele y menos arriesga, con vuelta atrás en cada paso. El MVP es una tajada vertical completa para un marketplace piloto en 6 semanas: los cuatro endpoints mínimos, seguridad completa y observabilidad. Lo que recorta es alcance funcional, nunca seguridad ni operación.
8.1 Estrategia y orden de migración
El patrón estrangulador (strangler fig) hace crecer lo nuevo alrededor de lo viejo y lo reemplaza por partes, sin un corte único.
| Paso | Qué se mueve | Integraciones del AS-IS que retira | Riesgo |
|---|---|---|---|
| 1 | Lecturas de stock y precio de un marketplace piloto | 7 y 8 (para ese partner) | Bajo: solo lectura, reversible cambiando una URL |
| 2 | Lecturas de todos los marketplaces | 7 y 8 | Bajo |
| 3 | Crear orden del marketplace piloto | 6 (para ese partner) | Medio: entra la saga |
| 4 | Crear orden de todos los marketplaces | 6 | Medio |
| 5 | Lecturas del e-commerce | 1 y 2 | Medio: es el canal de más tráfico |
| 6 | Órdenes y pago del e-commerce | 3 y 4 | Alto: es el canal propio |
| 7 | Clientes y puntos | 5 y 12 | Bajo |
| 8 | Integraciones internas (OMS con WMS y ERP, lote nocturno) | 9, 10, 11 | Se evalúa; puede no justificarse |
Los números de integración corresponden a las 12 flechas del C4 AS-IS: 1 y 2, e-commerce a ERP y WMS; 3, e-commerce a OMS; 4, e-commerce y pasarela; 5, e-commerce a CRM; 6, 7 y 8, marketplaces a OMS, WMS y ERP; 9 y 10, OMS a WMS y ERP; 11, lote nocturno de WMS a ERP; 12, OMS a CRM.
Cada paso pasa por cuatro etapas: sombra (la capa corre en paralelo y se comparan respuestas, sin afectar al canal), canario (un porcentaje pequeño del tráfico real), corte (todo el tráfico; la integración vieja apagada pero disponible dos semanas) y retiro (se eliminan credenciales y accesos directos al legado; sin este paso la integración vieja sigue siendo una puerta abierta).
Trade-off: durante la convivencia los canales no migrados venden sin reservar en la capa (riesgo R8). Se mitiga con un colchón mayor y migrando primero los canales de más órdenes.
8.2 MVP: 4 a 6 semanas
| Semana | Entrega |
|---|---|
| 1 | Plataforma base: clúster, pipeline, plantilla de servicio, Keycloak, gateway, observabilidad mínima. Contratos v1 acordados con el partner piloto. Validación del supuesto S1 |
| 2 | Adaptadores de ERP y WMS; modelo de lectura alimentado y comparado en sombra contra el legado |
| 3 | GET /v1/stock y GET /v1/prices en producción para el piloto; cuotas; prueba de carga 10x |
| 4 | Reservas e inventory-service con gRPC; order-service con idempotencia; payment-service contra el entorno de pruebas de la pasarela |
| 5 | Saga completa, adaptador del OMS, webhooks de orden confirmada y pago; órdenes del piloto en canario |
| 6 | Estabilización: runbooks, alertas, prueba de escenarios de falla, corte del piloto |
Lo que el MVP sí entrega:
- Los 4 endpoints mínimos del enunciado, para un partner.
- Webhooks: orden confirmada, pago aprobado y rechazado. Despacho y entrega si el WMS los expone sin trabajo adicional.
- Seguridad completa: no hay versión reducida de seguridad.
- Observabilidad: tableros, 6 alertas, runbook de stock y precio.
- Evidencia: p95 y carga al legado, antes y después.
Lo que el MVP no entrega, a propósito:
- Los demás marketplaces y el e-commerce.
- Integración con el CRM: el precio por segmento de cliente usa la lista por defecto del canal.
- Devoluciones, cancelaciones iniciadas por el cliente, órdenes con varias ubicaciones de despacho.
- Portal de desarrolladores y alta autónoma de partners.
- Multirregión.
- Cambios en las integraciones internas entre OMS, WMS y ERP.
Trade-off: un MVP de un solo partner demora el beneficio para el resto de los canales, a cambio de probar los dos flujos completos en producción con riesgo acotado.
8.3 A 3 meses
- Todos los marketplaces migrados en lecturas y órdenes; integraciones 6, 7 y 8 retiradas.
- E-commerce leyendo stock y precio por la capa.
- Adaptador del CRM: precio por segmento y aviso de compras para puntos.
- Webhooks de despacho y entrega para todos.
- Alta de partners guiada: plantilla de configuración, entorno de pruebas (sandbox), documentación publicada desde los contratos.
- Herramienta de reproceso de DLQ y reenvío de webhooks.
- Escenarios de falla y pruebas de comportamiento (F1, F2 y F6 a F10) corriendo en el pipeline como funciones de aptitud, y construidas las dos que hoy son diseño: la regla de dependencias (F3) y la comparación de contratos (F4), sección 3.8.
- Auditoría completa: registro en inventory, payment, webhook y el borde, y archivo con bloqueo contra modificación (sección 5.7).
- Primera promo real atendida con el plan de promos y revisión posterior.
8.4 A 6 meses
- Órdenes y pago del e-commerce por la capa; integraciones 1 a 5 retiradas.
- Devoluciones y cancelaciones como sagas propias (punto en que se revisa el motor de flujos, sección 4.4).
- Portal de desarrolladores, llaves autogestionadas, planes de consumo.
- Eventos ofrecidos a consumidores internos (analítica, fidelización) como producto.
- Evaluación de las integraciones internas 9 a 11: se migran solo si los datos de incidentes lo justifican.
- Recuperación ante desastres probada: restauración en una segunda región.
- Revisión de costos y de dimensionamiento con datos reales.
- Plantilla de adaptador probada con un sistema nuevo, para medir cuánto cuesta de verdad agregar uno.
8.5 Equipo y criterio de salida
Equipo supuesto: en el MVP, 1 arquitecto, 4 desarrolladores, 1 de plataforma, 1 de calidad y medio tiempo de seguridad (supuesto S17). De 3 a 6 meses, dos equipos de producto (lecturas y órdenes) sobre un equipo de plataforma.
Para que eso escale, el camino dorado (golden path: ruta estándar y ya resuelta para crear y operar un servicio) es parte del roadmap desde la semana 1: plantilla de servicio con health, logs JSON, lectura de secretos, pipeline, manifiestos y alertas base; plantilla de adaptador con bulkhead y circuit breaker; formato corto de rutas del gateway. Despliegue por GitOps (el clúster se sincroniza con lo que declara el repositorio), con imágenes inmutables y despliegue progresivo con vuelta atrás.
Una etapa termina cuando sus funciones de aptitud pasan en producción, no cuando se despliega el código: p95 bajo 300 ms con tráfico real, cero llamadas directas del canal migrado al legado y cero órdenes atascadas sin alerta.