Monolito de 180 000 líneas: ¿doce microservicios en un trimestre?
Una empresa de distribución en Colombia mantiene un monolito Java/Spring de 180 000 líneas que gestiona pedidos, inventario y facturación sobre una única base de datos. El equipo estable son 4 desarrolladores y 1 QA. Cada despliegue exige una ventana nocturna de 40 minutos y, en los últimos seis meses, 7 de 19 despliegues provocaron incidentes en producción; el más costoso bloqueó la facturación durante 3 horas. La gerencia leyó que «los microservicios escalan» y propone dividir el sistema en 12 servicios para el próximo trimestre. El módulo de pedidos tiene 34 dependencias directas hacia inventario y facturación, y las tres áreas comparten transacciones que abarcan sus tablas. El equipo no tiene experiencia con Kubernetes, colas ni observabilidad distribuida, y el esquema de base de datos está congelado hasta diciembre por una auditoría.
1. La gerencia le pide una opinión técnica por escrito sobre la propuesta de 12 microservicios. ¿Cómo la evalúa y qué recomienda?
Read the worked answer
Diagnóstico de los síntomas. 7 de 19 despliegues con incidentes y una ventana de 40 minutos indican acoplamiento interno y poca red de seguridad automatizada, no un problema de escala de despliegue. Partir el sistema en 12 servicios no elimina ese acoplamiento: lo convierte en un problema distribuido.
Criterios de decisión.
- Ley de Conway: 4 desarrolladores y 1 QA no pueden sostener 12 servicios con guardias, versionado de contratos, trazabilidad distribuida y entornos por servicio.
- Atomicidad: hoy pedidos, inventario y facturación comparten transacción. Extraerlos obliga a sagas y consistencia eventual justo donde hoy hay garantías ACID.
- Costo del primer incidente: sin observabilidad distribuida, diagnosticar un fallo en cadena toma horas; el equipo ya tardó 3 horas en un monolito que conoce.
Recomendación. Monolito modular: definir límites por contexto (pedidos, inventario, facturación), prohibir el acceso cruzado a repositorios ajenos, exponer contratos internos explícitos y separar esquemas lógicos. En paralelo, invertir en pipeline: pruebas automatizadas, despliegue incremental y feature flags para reducir la ventana de 40 minutos. Reevaluar la extracción cuando el monolito modular despliegue sin incidentes y exista un equipo por contexto. Los microservicios son consecuencia de la estructura organizacional, no un atajo para arreglarla.
2. Si el objetivo medible es reducir incidentes de despliegue y tiempo de puesta en producción en tres meses, proponga un plan concreto con acciones y métricas.
Read the worked answer
Línea base (semana 0). Medir: despliegues por mes, tasa de fallo de cambio (7/19 ≈ 37 %), tiempo medio de restauración y duración del despliegue (40 min). Sin línea base no se puede demostrar mejora.
Acciones por prioridad.
- Red de seguridad: pruebas automatizadas sobre los tres flujos que más dinero mueven (crear pedido, reservar inventario, emitir factura). Meta realista para 3 meses: cobertura de comportamiento en esos flujos, no 80 % global.
- Separar el despliegue de la liberación: feature flags para que el código entre a producción apagado y la activación sea independiente del artefacto.
- Migraciones compatibles: mientras el esquema está congelado, preparar migraciones en dos fases (expandir/contraer) para que el día que se descongele no se requiera ventana.
- Observabilidad mínima: logging estructurado con identificador de correlación y métricas de negocio (pedidos/minuto, facturas emitidas).
- Límites internos: reglas de arquitectura verificadas automáticamente (por ejemplo, tests de arquitectura) para que un módulo no llame a las tablas de otro.
Métricas de éxito a 90 días. Tasa de fallo de cambio por debajo de 15 %, duración del despliegue por debajo de 15 minutos, al menos un despliegue semanal, y cero incidentes que bloqueen facturación. Si el equipo no logra estas metas dentro del monolito, tampoco las logrará operando 12 servicios.
3. Suponga que seis meses después el monolito modular funciona bien y deciden extraer un primer servicio. ¿Cuál extraería y con qué criterios? Justifique.
Read the worked answer
Criterios, en orden de peso.
- Bajo acoplamiento transaccional: el candidato no debe participar en transacciones que hoy abarcan varias tablas. Este criterio descarta de entrada al núcleo de pedidos, que tiene 34 dependencias.
- Tasa de cambio y perfil de carga independientes: si un módulo cambia por razones distintas (por ejemplo, regulación tributaria) o tiene picos propios, separarlo aísla el riesgo.
- Propiedad clara: debe existir un equipo que lo sostenga; sin dueño, el servicio se convierte en huérfano.
- Datos separables sin romper integridad referencial.
Candidato recomendado. El camino de generación y entrega de documentos (PDF de factura, notificaciones al cliente) o la ruta de lectura/reportes, no el núcleo de pedidos ni inventario. Razones: es idempotente por naturaleza, tolera reintentos y consistencia eventual, tiene carga con picos distintos al transaccional, y su falla no bloquea la venta. Extraerlo valida la infraestructura (despliegue, colas, trazas, contratos) con un riesgo de negocio acotado.
Contraindicación. No extraer inventario primero: concentra la contención y las reglas de disponibilidad; un fallo ahí produce sobreventa, que es el peor resultado posible. Tampoco facturación, por su acoplamiento regulatorio y transaccional.
Preparación previa. Contrato explícito, pruebas de contrato, y una ruta de reversa (posibilidad de volver al monolito) durante el primer mes.