Qué preguntamos antes de proponer microservicios a una PYME

Cuando una PYME nos contacta preguntando por una migración a microservicios, la primera reunión casi nunca termina hablando de microservicios. Termina hablando del equipo que los va a operar, del dominio que se quiere partir y del ritmo al que cambia el negocio. Migrar sin resolver esas tres preguntas produce, casi siempre, un sistema más complejo que el que se quería reemplazar: la misma lógica de negocio, las mismas limitaciones de fondo, pero repartidas ahora en varios procesos, varias redes y varios lugares nuevos donde algo puede fallar. Por eso la primera conversación técnica con un cliente nuevo no arranca mirando el código. Arranca con preguntas que, en varios casos, terminan en la recomendación de quedarse en el monolito.

La primera pregunta: quién va a operar esto

Antes de hablar de límites de dominio o de bases de datos separadas, preguntamos por el equipo. Cuántas personas tocan el backend, cuánta experiencia tienen operando sistemas distribuidos, y quién responde si un servicio se cae un sábado a la madrugada. Un monolito bien escrito falla de formas limitadas: se cae el proceso, se reinicia, y en el peor caso hay un rollback de un solo deploy. Un sistema de microservicios falla de formas que un monolito no conoce: una llamada entre servicios que se queda colgada sin timeout, un mensaje que se procesa dos veces porque el consumidor no es idempotente, una cascada de reintentos que satura al servicio que ya estaba con problemas. Operar eso bien requiere observabilidad distribuida, trazas correlacionadas entre servicios y alguien que sepa leerlas bajo presión.

Cuando el equipo backend de un cliente son tres o cuatro personas sin experiencia previa operando sistemas distribuidos, la conversación no es si técnicamente se puede dividir el monolito. Casi siempre se puede. La conversación es si ese equipo, en producción, va a poder diagnosticar por qué el checkout falla intermitentemente cuando la causa está en la comunicación entre dos servicios y no en uno solo. Si la respuesta honesta es que no, proponer microservicios en ese momento no resuelve el problema que el cliente tiene: se lo cambia por uno más difícil de depurar con el equipo que ya tiene.

La segunda pregunta: dónde están los límites reales del dominio

Microservicios exige partir el dominio en piezas que cambian y escalan de forma independiente. Esto suena directo hasta que se intenta hacer sobre un dominio real. Pedimos ver el modelo de datos actual y preguntamos, campo por campo de las tablas más grandes, quién lee y quién escribe cada uno. La respuesta habitual en una PYME con pocos años de operación es que casi todo lo lee y escribe el mismo puñado de casos de uso, porque el negocio todavía no tiene la escala ni la variedad de flujos que justificarían fronteras separadas.

Un ejemplo típico: un cliente con un sistema de pedidos e inventario nos pidió separar ambos en servicios distintos porque "es lo que se hace". Al revisar el modelo encontramos que cada operación de negocio que tocaba pedidos tocaba inventario en la misma transacción, sin excepción, y que no existía ningún caso de uso donde uno cambiara sin el otro. Separarlos en dos servicios habría significado convertir una transacción local en una operación distribuida —con sus problemas de consistencia asociados— sin que ningún beneficio real de independencia lo compensara, porque en la práctica los dos "servicios" siempre se desplegaban y cambiaban juntos. La frontera de dominio que había que respetar no era pedidos-inventario; era todo el flujo de checkout separado del catálogo de productos, que sí cambiaba a ritmos distintos y lo tocaban equipos distintos.

Este tipo de revisión también nos sirve para detectar el caso contrario: cuando sí hay una frontera clara pero está enterrada dentro del monolito por cómo se organizó el código, no por cómo se organiza el negocio. Ahí la recomendación cambia.

La tercera pregunta: a qué ritmo cambia cada parte

La última pregunta es sobre velocidad de cambio, no sobre volumen de tráfico. Microservicios ayuda cuando distintas partes del sistema necesitan desplegarse en ciclos distintos: el equipo de catálogo quiere lanzar cambios varias veces por semana, mientras que el módulo de facturación casi no se toca porque depende de integraciones regulatorias que cambian una vez al año. Esa asimetría de ritmo es la que justifica pagar el costo de separar procesos, porque el beneficio concreto es que un deploy del catálogo deja de requerir coordinar un release completo del sistema de facturación.

Cuando todo el sistema cambia al mismo ritmo —porque el equipo es pequeño y todos los cambios pasan por las mismas dos o tres personas—, esa asimetría no existe todavía, y separar procesos sin ella suma el costo de coordinación entre servicios sin el beneficio que se supone que lo paga.

Lo que no funcionó: empezar por el análisis de código

En los primeros proyectos donde evaluamos una migración, empezábamos por el lado técnico: leíamos el repositorio, identificábamos módulos con bajo acoplamiento entre sí, y proponíamos una descomposición basada en esa estructura de código. El análisis técnico salía bien, pero la propuesta chocaba en la práctica porque no habíamos preguntado antes si el equipo podía operar el resultado ni si esas fronteras de código coincidían con fronteras de negocio reales. Terminamos entregando arquitecturas correctas en el papel que el cliente no podía sostener seis meses después, porque el problema operativo que habíamos ignorado en la primera conversación aparecía de todas formas, solo que más tarde y ya en producción.

Cambiar el orden —equipo, dominio, ritmo de cambio, y solo después el código— no cambió la calidad del análisis técnico en sí. Cambió qué preguntas hacíamos antes de comprometernos con una recomendación, y evitó que propusiéramos algo técnicamente correcto pero operativamente inviable para ese cliente en particular.

Cuándo la recomendación es quedarse en el monolito

La recomendación de no migrar aparece con más frecuencia de la que uno esperaría al empezar en esto. Aparece cuando el equipo no tiene todavía la experiencia operativa para sostener un sistema distribuido, cuando el dominio no muestra fronteras naturales que se puedan separar sin duplicar transacciones que hoy son locales, o cuando todas las partes del sistema cambian al mismo ritmo y ninguna se beneficiaría de desplegarse sola. En esos casos, la alternativa que solemos proponer no es "no hacer nada": es modularizar el monolito internamente, con límites de código explícitos entre las partes que algún día podrían separarse, de forma que la opción quede abierta sin pagar hoy el costo operativo completo de un sistema distribuido que el equipo todavía no puede sostener.