Cuando los microservicios hacen más daño que bien
Por qué los equipos pequeños pierden velocidad con microservicios prematuros y cuándo un monolito modular es una mejor arquitectura.
Los microservicios suelen presentarse como el camino por defecto hacia la escala, así que los equipos en fases tempranas copian la arquitectura de empresas que operan en condiciones totalmente distintas. En la práctica, eso suele significar heredar complejidad de sistemas distribuidos mucho antes de tener la estructura de equipo necesaria para sostenerla.
Los microservicios resuelven problemas de escalado organizacional tanto como problemas técnicos. Si un equipo de cinco personas divide un MVP en diez servicios, crea pipelines de despliegue, contratos entre servicios, necesidades de observabilidad y modos de fallo que ese mismo equipo pequeño tendrá que mantener cada día.
Los costes ocultos aparecen rápido. Las llamadas a función pasan a ser llamadas de red, con latencia, reintentos y fallos. La consistencia de datos se vuelve más difícil porque las transacciones atómicas dejan de existir dentro de una única frontera de base de datos. Y depurar errores se vuelve lento porque ahora hay que seguir la petición a través de varios servicios.
La sobrecarga operativa también crece. Los equipos necesitan mejor logging, tracing distribuido, service discovery, gestión de secretos y respuesta a incidentes solo para mantenerse donde estaban. Las facturas cloud suben porque la plataforma paga coordinación, no solo valor de negocio.
Para la mayoría de los equipos, un monolito bien estructurado es un mejor punto de partida. Un código modular guiado por Domain-Driven Design puede separar responsabilidades sin convertir cada frontera lógica en una frontera de red.
Un servicio debería extraerse solo cuando realmente tiene necesidades de despliegue, propiedad o escalado distintas al resto de la aplicación. Hasta entonces, la arquitectura más rápida suele ser la que mantiene el sistema simple, no la que parece más distribuida en un diagrama.