Cuando escuchas "microservicios", probablemente piensas en independencia.
No es casual. Durante años esa fue la promesa central: dividir el sistema en piezas pequeñas que pudieran evolucionar por separado. Equipos autónomos, despliegues independientes, tecnologías distintas conviviendo sin bloquearse.
Suena convincente. Y lo es, por lo menos durante un tiempo.
Pero hay algo que empieza a suceder cuando esos sistemas crecen. No aparece el primer día. No aparece en los diagramas iniciales. Aparece después, cuando el producto se vuelve complejo, cuando el frontend deja de ser trivial, cuando varios equipos empiezan a tocar la misma experiencia.
Los microservicios comienzan a depender entre sí.
Y lo más incómodo es que muchas veces esa dependencia no aparece primero en el backend.
Aparece en el frontend.
No lo voy a explicar todavía, porque antes vale la pena entender cómo llegamos aquí.
El concepto de microservicios surge como una reacción. A principios de los 2000, las arquitecturas SOA prometían reutilización y desacoplamiento, pero en la práctica derivaron en ESB centralizados, contratos rígidos y despliegues coordinados. La flexibilidad que buscaban terminó atrapada en capas de gobernanza y burocracia que a menudo dependía de proveedores externos.
A inicios de la década de 2010, empresas como Netflix empezaron a descomponer sus monolitos para poder escalar. No lo hicieron por elegancia arquitectónica, sino porque el modelo anterior no les permitía moverse con suficiente rapidez. Cada cambio implicaba coordinar demasiadas partes. La descomposición en servicios más pequeños les permitió aislar dominios y desplegar con mayor frecuencia.
En 2014, Martin Fowler y James Lewis popularizaron el término "microservices" y le dieron forma al estilo: servicios pequeños, alineados al dominio de negocio, desplegables de forma independiente. La narrativa era potente porque respondía a un problema real: el monolito estaba frenando la velocidad de los equipos.
A partir de ahí, la industria abrazó la idea. Docker, Kubernetes y la nube facilitaron la adopción. Cada pieza del ecosistema reforzaba la misma intuición: si dividimos, ganamos independencia.
Pero la independencia que se gana es local. Cada servicio puede evolucionar por separado, sí. El problema es que el producto sigue siendo una experiencia única. Y esa experiencia tiene que recomponerse en algún lugar.
Ese lugar suele ser el frontend.
Imagina un sistema correctamente dividido. Un servicio para usuarios, otro para catálogo, otro para órdenes, otro para pagos. Cada uno con su base de datos, su pipeline, su equipo. Arquitectónicamente todo parece limpio.
Luego construyes la interfaz.
La pantalla principal necesita mostrar información del usuario, sus órdenes recientes, el estado de pago y la disponibilidad del catálogo. El frontend empieza a orquestar llamadas. Empieza a componer respuestas. Empieza a decidir qué datos necesita y en qué orden.
En ese momento ocurre algo sutil. Los microservicios dejan de ser completamente independientes. No porque compartan código, sino porque comparten una experiencia.
Un cambio en el flujo visual obliga a modificar contratos. Un ajuste en la composición de datos requiere coordinar varios servicios. El frontend se convierte en el punto donde las fronteras vuelven a difuminarse.
Esto no suele doler al inicio. Pero a medida que el producto crece, empiezan a aparecer síntomas.
Un deploy pequeño requiere coordinar varios equipos.
Una modificación en la UI rompe un servicio que no esperaba ese cambio.
El debugging implica seguir trazas a través de múltiples dominios.
La latencia acumulada empieza a ser visible.
La independencia sigue existiendo, pero cada vez más condicionada.
Aquí es donde surgen patrones que intentan recuperar el control. Backend for Frontend, API Gateway, GraphQL. Todos buscan evitar que el frontend tenga que conocer demasiados detalles de los servicios. Pero cada uno introduce una nueva capa de coordinación.
El BFF agrega y transforma datos. GraphQL centraliza el esquema. El gateway define rutas y políticas. Son soluciones útiles, pero no eliminan el acoplamiento. Lo reorganizan.
Y luego aparece la evolución natural: microfrontends. Si dividimos el backend, ¿por qué no dividir también el frontend? La idea es coherente. Cada equipo controla su parte visual, su despliegue, su ritmo.
Sin embargo, la experiencia del usuario sigue siendo única. La navegación es compartida. La autenticación es común. El diseño debe ser consistente. El estado global reaparece. Poco a poco, las dependencias vuelven a emerger.
No porque la arquitectura sea incorrecta, sino porque el producto exige coherencia.
Las historias de éxito ayudan a entender cuándo esto funciona. Netflix logró escalar globalmente con microservicios, pero invirtió fuertemente en observabilidad y resiliencia. Amazon construyó su cultura de equipos pequeños apoyándose en servicios independientes, pero acompañó esa independencia con contratos bien definidos y tooling interno. Spotify organizó sus squads alrededor de dominios que podían moverse con autonomía, pero mantuvo mecanismos de alineación para evitar divergencias.
En todos esos casos, la independencia no era automática. Era el resultado de disciplina técnica y organizacional.
También existen historias donde el entusiasmo inicial llevó a una complejidad difícil de manejar. Shopify ha hablado de la necesidad de volver a enfoques más modulares para reducir la sobrecarga operativa. Uber reorganizó partes de su arquitectura cuando el número de servicios dificultaba la evolución. Incluso Amazon ha reconocido problemas derivados de tener demasiados servicios pequeños y altamente coordinados. No se trataba de abandonar los microservicios, sino de reconocer que la independencia absoluta no existe.
Ahí aparece el trade-off real. Los microservicios permiten escalar equipos y dominios, pero introducen latencia, coordinación, observabilidad distribuida y dependencias de red. Reducen el acoplamiento dentro del código, pero lo trasladan a los contratos y a la experiencia integrada. Permiten despliegues independientes, pero requieren gobernanza para no romper la composición.
Y cuando el frontend entra en juego, ese equilibrio se vuelve más delicado. Porque el frontend es el punto donde todas las piezas independientes vuelven a encontrarse.
Tal vez la idea más incómoda es esta: los microservicios no eliminan la dependencia. Cambian su forma. En un monolito, la dependencia es visible en el código. En microservicios, la dependencia es implícita en la red y en el frontend. Sigue existiendo, pero es menos evidente y más difícil de rastrear.
La independencia prometida no desaparece, pero se vuelve relativa. Cada servicio puede evolucionar por separado, pero el producto obliga a coordinar. Cada equipo tiene autonomía, pero la experiencia del usuario exige coherencia.
Ahí es donde la arquitectura deja de ser una búsqueda de independencia absoluta y se convierte en un equilibrio entre autonomía y consistencia.
Si has trabajado con microservicios, probablemente hayas vivido ese momento. Ese momento donde un cambio pequeño termina involucrando varios servicios y también el frontend. Ese momento donde la independencia empieza a sentirse menos clara.
Me interesa saber si te ha pasado. Puedes responder este correo y contármelo.