La Pregunta Que Recibo Antes de que el Producto Siquiera Salga
Un fundador me llamó el trimestre pasado por una herramienta interna usada por once empleados, con un plan de crecimiento de quizás cuarenta más en los próximos dos años. Su primera pregunta no fue sobre el roadmap ni el presupuesto. Fue si su equipo debía "empezar con microservicios para no tener que reconstruir todo después." He tenido una versión de esta conversación más veces de las que puedo contar, y la respuesta honesta es casi siempre la misma: no, todavía no, y posiblemente nunca.
Las decisiones de arquitectura en las PyMEs en crecimiento suelen estar impulsadas por lo que recomendó una charla de conferencia de una empresa cincuenta veces más grande, no por lo que su tráfico real, su equipo y su presupuesto pueden sostener. Netflix y Uber operan sistemas distribuidos que encajan con su escala y con miles de ingenieros en su plantilla. Eso no significa que la misma arquitectura le sirva a una empresa SaaS de doce personas que procesa unos pocos miles de transacciones al día. Copiar la arquitectura de una empresa que no es la suya, a una escala que no tiene, es uno de los errores más caros que veo cometer a las PyMEs.
Qué le da Realmente Cada Arquitectura
Un monolito es una aplicación desplegable como una sola unidad: un código base, un pipeline de build, un despliegue, generalmente una base de datos. Cada parte del sistema puede llamar directamente a cualquier otra, en el mismo proceso, sin un salto de red de por medio. Desplegar es simple. Depurar es simple. Un solo desarrollador puede tener la mayor parte del sistema en la cabeza.
Los microservicios dividen esa misma funcionalidad en servicios desplegables de forma independiente, cada uno normalmente con su propia base de datos, comunicándose por red mediante APIs o colas de mensajes. Cada servicio se puede construir, desplegar y escalar con su propio calendario. Esa independencia tiene un valor genuino, una vez que se tiene el tamaño de equipo y el volumen de tráfico que justifican la sobrecarga que genera.
El monolito modular es la opción que más recomiendo a las PyMEs en crecimiento, y rara vez recibe atención en los debates de arquitectura porque es menos llamativo hablar de él. Es una única aplicación desplegable, organizada internamente en módulos bien definidos con límites reforzados entre ellos. En lo operativo se comporta como un monolito: un despliegue, un proceso, una sola guardia de soporte. Internamente está estructurado como microservicios: propiedad clara por módulo, bajo acoplamiento, interfaces explícitas. Explico cómo construir bien esos límites internos en mi artículo sobre arquitectura limpia en .NET. Bien hecho, un monolito modular es barato de operar hoy y genuinamente fácil de dividir más adelante, porque las costuras ya existen en el código.
El Costo Real de Dividir Demasiado Pronto
Cada servicio que se agrega a un sistema distribuido trae su propio pipeline de CI/CD, su propio monitoreo y logging, su propia superficie de guardia y sus propios modos de falla. Una llamada a función que antes tomaba microsegundos dentro del mismo proceso ahora se convierte en una petición de red que puede tardar demasiado, reintentar o fallar a mitad de camino. Los datos que antes vivían en una sola base de datos consistente ahora se duplican entre servicios, y mantenerlos sincronizados introduce problemas de consistencia eventual que antes no existían. Nada de esto es teórico: es la realidad diaria de operar un sistema distribuido, y lo considero una forma de deuda técnica oculta que la mayoría de los equipos subestima hasta que ya la están viviendo.
Dos ejemplos conocidos ilustran esto mejor que cualquier explicación mía. En 2018, Segment publicó un relato muy leído sobre cómo consolidó cerca de 140 microservicios de vuelta en un único servicio monolítico, citando la carga operativa de mantener tantas piezas desplegadas de forma independiente como el motivo principal. En 2023, el propio equipo de ingeniería de Prime Video de Amazon describió cómo movió un componente de monitoreo de calidad de video de una configuración distribuida y serverless hacia un único proceso monolítico, reportando una reducción del 90% en el costo de infraestructura para esa carga de trabajo específica. Ninguna de estas empresas es anti-microservicios; ambas siguen usando muchos en otras partes de su sistema. La lección es más puntual y más útil: hacer que la arquitectura coincida con la carga de trabajo real, no con la arquitectura de moda ese año.
Para una PyME, el costo adicional suele aparecer como una contratación de plataforma o DevOps que no estaba presupuestada, una factura de nube que crece más rápido que su base de usuarios, y una velocidad de entrega de funcionalidades que se reduce en lugar de aumentar, porque cada cambio ahora toca contratos entre servicios en vez de un solo código base.
Un Marco: Cinco Preguntas Antes de Dividir
Antes de recomendar una división, pido a mis clientes que respondan con honestidad esto:
- ¿Necesitan realmente escalar de forma independiente distintas partes del sistema, respaldado por datos reales de uso y no por una hipótesis sobre crecimiento futuro?
- ¿Tienen, o pueden costear, a una persona dedicada a la complejidad operativa —pipelines de despliegue, monitoreo, respuesta a incidentes— separada de quienes construyen funcionalidades?
- ¿Existen límites organizacionales genuinos: equipos separados que necesitan desplegar de forma independiente sin pisarse entre sí?
- ¿El dolor de despliegue actual lo causa realmente la arquitectura, o son vacíos de proceso —falta de CI/CD, de feature flags, de un entorno de staging?
- ¿Dividir resolvería un cuello de botella técnico medible, o principalmente haría que el organigrama luzca más sofisticado ante inversores o nuevas contrataciones?
Si la respuesta a dos o más de estas preguntas es "no," quédense con un monolito, idealmente modular. El dolor que intentan evitar suele ser más pequeño que el dolor que crearían.
Un Escenario que Veo Seguido
Un cliente fintech B2B llegó a mí queriendo dividir un motor de conciliación en un servicio de libro contable, uno de reportes y uno de notificaciones antes de escribir una sola línea de código en producción, por miedo a "chocar contra un muro" más adelante. En su lugar recomendé un monolito modular: una aplicación desplegable con la lógica del libro contable, los reportes y las notificaciones viviendo en módulos claramente separados, cada uno con su propia interfaz y sin acceso directo a los datos de otro módulo. Entregamos el MVP en unas diez semanas en vez de las veinte o más que habría exigido una construcción distribuida, con un solo equipo, un solo pipeline de despliegue y una sola base de datos de la cual preocuparse.
Dieciocho meses después, finalmente apareció la señal para dividir: las consultas de reportes competían con las escrituras transaccionales por los mismos recursos de base de datos durante el cierre de mes, y ese cuello de botella específico era medible, no hipotético. Como los límites entre módulos ya existían en el código, extraer los reportes a su propio servicio tomó unas pocas semanas en lugar de una reescritura completa.
El Camino de Migración Cuando Sí Hace Falta Dividir
Cuando llega una necesidad real y medida de microservicios, el camino más seguro es el patrón Strangler Fig: extraer un módulo delimitado a la vez detrás de una interfaz estable, correr la implementación antigua y la nueva en paralelo, redirigir el tráfico gradualmente, y retirar el código viejo solo una vez que confíen en el nuevo servicio bajo carga real. Es la misma disciplina incremental que recomiendo a los equipos que atraviesan migraciones a la nube más amplias: las reescrituras de una sola vez fallan con mucha más frecuencia que las transiciones por etapas, sin importar si el destino es un nuevo proveedor de nube o un nuevo límite de servicio.
Entonces, ¿Cuál Deberían Elegir?
Empiecen con un monolito modular, a menos que ya tengan evidencia concreta y medida de que partes específicas de su sistema necesitan escalar, desplegarse o fallar de forma independiente del resto. La arquitectura debe seguir sus restricciones reales —tamaño de equipo, tráfico y estructura organizacional— no sus aspiraciones sobre dónde podría estar la empresa dentro de cinco años. Prefiero ayudarlos a evitar un desvío arquitectónico costoso antes que verlos tomarlo.