Hey cracks, en esta ocasión te tengo un artículo que más es una historia basada en mi experiencia, ojalá te sirva y te guste.

Cuando creí haber encontrado la arquitectura perfecta

Durante mucho tiempo pensé que la evolución natural de cualquier sistema serio terminaba en microservicios, seguro a ustedes cracks les habrá pasado algo parecido ya sea con microservicios, o clean architecture, en fin, aquí vamos a desmontar mitos.

Cuando empecé a estudiar arquitectura moderna, todo parecía apuntar hacia ahí: despliegues independientes, escalado por servicio, equipos autónomos, resiliencia, menor acoplamiento y libertad tecnológica. Sonaba como el siguiente nivel. Si las grandes empresas lo hacían, parecía lógico asumir que ese era el camino correcto.

Como muchos developers, cometí el mismo error: empecé a ver los microservicios como una meta, no como una decisión arquitectónica.

Si había que construir una nueva plataforma, microservicios.
Si era una API interna para una empresa pequeña, también microservicios.
Si el sistema apenas estaba empezando, mejor aún: “hay que hacerlo bien desde el inicio”.

Mientras más servicios había, más sensación de arquitectura “seria” parecía existir.

Cuando la realidad empezó a pasar factura

El problema apareció cuando la complejidad dejó de ser una diapositiva bonita y se volvió parte del trabajo diario.

Lo que antes era una sola aplicación pasó a convertirse en múltiples servicios, múltiples despliegues, observabilidad distribuida, trazabilidad entre procesos, fallos de red, timeouts, retries, circuit breakers, consistencia eventual y problemas que simplemente no existían dentro de un monolito bien diseñado.

De pronto, resolver una funcionalidad sencilla implicaba coordinación entre varios servicios, más reuniones, más puntos de falla y más tiempo invertido en infraestructura que en entregar valor al negocio.

No era mala arquitectura.

Era una mala decisión arquitectónica.

Martin Fowler lo explica bastante bien: los microservicios no son una mejora automática sobre un monolito. Son un intercambio. Ganas independencia de despliegue y límites más fuertes entre módulos, pero pagas con complejidad operativa, distribución y mayores exigencias de madurez técnica y organizacional. Incluso él menciona algo clave: si puedes manejar la complejidad de tu sistema con un monolito bien estructurado, probablemente no deberías usar microservicios.

La arquitectura no existe para impresionar developers

Fue ahí cuando entendí algo importante: la arquitectura no existe para impresionar colegas, leads, equipos ni jefes.

Existe para resolver problemas.

Si tienes equipos grandes, dominios bien definidos, necesidad real de escalado independiente y una operación madura, los microservicios pueden ser una gran decisión.

Pero si estás resolviendo un problema simple, con un equipo pequeño y sin una necesidad real de distribución, fragmentar el sistema demasiado pronto no es visión técnica; es sobreingeniería.

Muchas veces, un monolito modular bien diseñado ofrece mejor velocidad, menor costo y menos fricción que una colección de servicios mal divididos.

A veces, el mejor diseño no consiste en dividir más, sino en mantener simple lo que todavía debe ser simple.

La verdadera madurez técnica

Hoy sigo considerando los microservicios una excelente herramienta, pero ya no los veo como una meta obligatoria.

Primero pienso en el problema. Después, en la arquitectura.

Un monolito bien diseñado puede ser mucho más profesional que diez microservicios mal justificados.

Con el tiempo entendí que la verdadera madurez técnica no está en adoptar lo más complejo, sino en elegir lo más adecuado para cada situación, en tiempo, presupuesto y forma.

No toda aplicación necesita microservicios.

Toda aplicación sí necesita decisiones conscientes y evitar la sobre ingeniería.

Ahora ya lo sabes crack!

Si esta entrada te ha gustado, compártela ps! 🐿️🙌

Créditos de imagen de portada: Foto de Leo_Visions en Unsplash