He visto aplicaciones monolíticas funcionando perfectamente, pero cuando a los jefes les da por leer demasiados blogs de ingeniería de Netflix... vamos a reescribir todo en 30 microservicios independientes usando Node.js y Docker. Ay Dios....

Ahora, para cargar la página de inicio del usuario, el sistema hace catorce llamadas HTTP internas. La web tarda tres segundos en responder, la base de datos tiene bloqueos por todos lados y el equipo de cinco programadores gasta más tiempo configurando balanceadores de carga que programando funcionalidades. Han construido un "monolito distribuido", la peor de todas las arquitecturas posibles.

Las falacias de la computación distribuida

Cuando desarrollas un monolito, si la función CrearPedido() necesita verificar el stock, hace una llamada en memoria a ConsultarStock(). El tiempo de ejecución es de nanosegundos y, lo más importante, si falla, usas una transacción SQL clásica:

-- Transacción ACID clásica en un monolito
BEGIN TRANSACTION;
    INSERT INTO Pedidos (Id, Total) VALUES (123, 50.00);
    UPDATE Stock SET Cantidad = Cantidad - 1 WHERE ProductoId = 9;
COMMIT;

Cuando pasas a microservicios, esa llamada en memoria se convierte en una petición HTTP por la red interna. La red tiene latencia, puede fallar, y los paquetes se pierden. Y lo peor de todo: no puedes hacer un BEGIN TRANSACTION mágico que bloquee simultáneamente la base de datos de PostgreSQL del Servicio de Pedidos y la base de datos MongoDB del Servicio de Inventario.

Si el inventario falla, tienes que programar lógica de compensación manual (el patrón Saga) para deshacer el pedido. Estás inyectando toda la complejidad de los sistemas distribuidos en tu código de negocio.

Reflexión: Un problema organizativo, no técnico

Los microservicios son brillantes, pero no solucionan un problema técnico de rendimiento (de hecho, añaden mucha latencia por la serialización JSON en cada salto de red). Los microservicios solucionan un problema organizativo.

Si eres Amazon, Spotify o Uber y tienes 500 ingenieros peleándose por hacer git merge en el mismo repositorio, la fricción de despliegue es inasumible. En ese escenario, aislar a los equipos en microservicios independientes con sus propias bases de datos y ciclos de despliegue es supervivencia pura. Permite que el equipo A suba a producción sin avisar al equipo B.

Pero si sois cinco desarrolladores en una oficina pequeña, un monolito bien estructurado con una arquitectura limpia (como MVC puro o Hexagonal) es vuestra mejor arma. La industria ha olvidado la belleza de la simplicidad. Romper un monolito solo por moda tecnológica, sin tener la madurez DevOps para monitorizar trazas distribuidas o coordinar orquestadores complejos, es un suicidio técnico garantizado.