Empecemos por la escena típica. Un equipo de ingeniería de 15 o 20 personas decide que "ya es hora" de migrar a una arquitectura de microservicios. El monolito "no escala". El deploy "es lento". Alguien leyó el post de Netflix sobre cómo dividieron todo en cientos de servicios y lo mandó al canal de arquitectura con un "miren esto". Seis meses después tienen doce microservicios, un service mesh a medio configurar, tres formas distintas de hacer logging entre equipos, y un incidente de producción que tardó cuatro horas en diagnosticar porque nadie sabía en cuál de los doce servicios estaba realmente el bug.
Nada de esto es ficción. Es el patrón más repetido en las migraciones a arquitectura de microservicios que arrancan sin tener claro qué problema están resolviendo.
Y esa es la idea central de este texto, dicha sin vueltas: la mayoría de los equipos que migran a microservicios no tienen el problema que los microservicios resuelven. Migran porque es lo que hacen las empresas grandes, porque queda bien en el currículum poner "arquitectura distribuida", o porque alguien vio un diagrama bonito en una charla y quiso replicarlo. El resultado casi siempre es el mismo: más complejidad operativa a cambio de nada.
El problema que en realidad estás resolviendo (o no)
Los microservicios no existen para que el código se vea más prolijo. Existen para resolver un problema muy específico: equipos grandes que necesitan trabajar de forma independiente sobre partes distintas de un sistema, sin bloquearse entre sí, y con la posibilidad de escalar o desplegar esas partes por separado.
Si tu equipo tiene ocho personas, ese problema no existe. Ocho personas pueden coordinarse en un monolito sin pisarse todo el tiempo. Pueden hacer code review cruzado, entender el sistema completo, y desplegar todo junto sin que eso implique un comité de cambios. La arquitectura de microservicios no te da nada ahí. Lo único que te da es una superficie de fallos distribuida, latencia de red donde antes había una llamada a función, y un problema de consistencia de datos que en un monolito ni siquiera existía.
La pregunta que casi nadie se hace antes de migrar es simple: ¿cuál es el cuello de botella real hoy? Si la respuesta es "los deploys tardan mucho" o "el código está desordenado", ese es un problema de disciplina de ingeniería, no un problema de arquitectura. Se resuelve con mejores pipelines de CI, con módulos internos bien separados, con boundaries de dominio claros dentro del mismo monolito. No se resuelve partiendo el sistema en pedazos que ahora se comunican por red.
Por qué la arquitectura de microservicios se volvió el estándar de facto
Hay una razón cultural detrás de esto y vale la pena decirla en voz alta: microservicios suena a ingeniería seria. Es lo que hacen Netflix, Amazon, Uber. Ponerlo en un roadmap técnico da la sensación de estar construyendo algo a la altura de esas empresas, incluso cuando el tráfico real del producto es una fracción minúscula del que tienen ellas.
El problema es que esas empresas no migraron a microservicios porque leyeron que era la tendencia. Migraron porque tenían miles de ingenieros trabajando sobre el mismo sistema y el monolito se había vuelto, literalmente, imposible de tocar sin romper algo en otro lado. Netflix no dividió su arquitectura para verse bien en una conferencia. Lo hizo porque coordinar a cientos de equipos sobre un único deploy era inviable.
Copiar la solución sin tener el problema es el error de fondo. Es como comprar el mismo auto de carrera que usa un piloto profesional pensando que eso te va a hacer manejar mejor. La herramienta no compensa la ausencia del problema que la hizo necesaria.
Cuándo el dolor organizacional sí justifica una arquitectura de microservicios
Dicho esto, hay casos reales, concretos, donde migrar a arquitectura de microservicios es la decisión correcta. Vale la pena nombrarlos con precisión porque la respuesta correcta no es "nunca microservicios", es "microservicios cuando el problema es este".
El primero es el más común entre empresas que ya crecieron: equipos grandes pisándose en un monolito. Cuando tienes 60, 80, 150 ingenieros tocando el mismo repositorio, los merges se vuelven una pesadilla, el deploy de un equipo bloquea al del resto, y un bug en un módulo de facturación tumba el checkout completo porque todo corre en el mismo proceso. Ahí sí hay un problema real de coordinación que la separación en servicios independientes resuelve, porque le da a cada equipo su propio ciclo de deploy, su propio dominio de fallos, y su propia cadencia de release.
El segundo caso es la necesidad genuina de escalar partes del sistema de forma independiente. Un ejemplo típico: tienes un servicio de procesamiento de imágenes que consume diez veces más CPU que el resto de la aplicación, y en un monolito eso te obliga a escalar horizontalmente toda la aplicación solo para darle más recursos a esa pieza. Separarlo en un servicio propio te permite escalarlo según su propia curva de demanda, sin arrastrar el resto del sistema. Esto es distinto de "vamos a partir todo por las dudas": es una decisión basada en una métrica de uso de recursos que ya duele hoy.
El tercer caso, el más difícil de identificar correctamente, son los dominios de negocio genuinamente desacoplados. No "módulos distintos del mismo dominio", sino dominios que tienen ciclos de vida, reglas de negocio y stakeholders completamente separados. El sistema de facturación de una empresa y su motor de recomendaciones, por ejemplo, casi nunca necesitan cambiar al mismo tiempo, ni los entiende el mismo equipo, ni comparten modelo de datos de forma natural. Ahí separar tiene sentido no solo técnico sino organizacional.
Fíjate en el patrón: en los tres casos, el dolor existe antes de la arquitectura. No se migra "para prevenir" un problema hipotético de escala. Se migra porque el problema ya está pasando y cuesta dinero, tiempo o gente todos los días.
El costo real que nadie pone en el slide de arquitectura
Cuando el problema no existe, migrar a microservicios no es neutral. Tiene un costo concreto que se paga en varios frentes a la vez.
El primero son los deploys. Pasar de "un deploy, una aplicación" a "veinte deploys coordinados con versiones compatibles entre sí" multiplica la superficie de cosas que pueden salir mal. Ahora necesitas versionado de contratos entre servicios, feature flags para despliegues graduales, y un pipeline de CI/CD por cada servicio en lugar de uno solo.
El segundo es la observabilidad. En un monolito, un stack trace te dice exactamente dónde falló algo. En un sistema distribuido, ese mismo error puede haber cruzado cinco servicios antes de manifestarse, y sin tracing distribuido bien implementado (que no es gratis de construir ni de mantener) vas a pasar horas reconstruyendo a mano el camino que siguió una request.
El tercero es la consistencia de datos. En un monolito, una transacción de base de datos te da atomicidad prácticamente gratis. En un sistema de microservicios, esa misma operación ahora involucra múltiples bases de datos independientes, y de repente estás implementando patrones como saga o eventual consistency para resolver un problema que antes se resolvía con un `BEGIN` y un `COMMIT`.
El cuarto es la latencia de red. Cada llamada a función que antes costaba nanosegundos ahora es una llamada HTTP o gRPC que cruza la red, con su propio presupuesto de latencia, sus propios timeouts, y su propia probabilidad de fallo. Un flujo que antes eran tres funciones seguidas ahora son tres servicios que se llaman entre sí, y cualquiera de esas tres llamadas puede fallar de formas que un monolito nunca tuvo que manejar.
Ninguno de estos costos es intrínsecamente malo. Son el precio de resolver el problema de coordinación de equipos grandes o de escalado independiente. El problema es pagarlos sin necesidad, porque entonces son puro costo sin ningún beneficio del otro lado.
Cómo saber en qué lado estás parado hoy
Hay una prueba simple, casi incómoda, que sirve para diagnosticar en qué situación está realmente tu equipo. Preguntáte: si mañana congeláramos el equipo tal como está, ¿el monolito seguiría siendo un problema? Si la respuesta es no, porque el dolor viene de que el equipo va a crecer, de que "en algún momento" vas a necesitar escalar una parte, o de que "se ve mejor" en una arquitectura distribuida, entonces no tienes un problema de arquitectura. Tienes una intuición sin datos.
Si en cambio la respuesta es sí, porque hoy mismo hay equipos bloqueándose, hoy mismo hay una parte del sistema que consume recursos desproporcionados, o hoy mismo hay dos dominios de negocio que se estorban al compartir código, entonces sí hay un caso real. Y en ese caso, la arquitectura de microservicios no es una moda: es la herramienta correcta para un problema que ya está costando dinero.
Nombra el problema antes de dibujar el diagrama de servicios
La arquitectura de microservicios no es buena ni mala. Es una herramienta con un costo operativo alto que solo se justifica cuando resuelve un problema de coordinación de equipos o de escalado que ya existe, no uno que imaginas que vas a tener. Migrar sin ese problema no te hace una empresa más madura técnicamente. Te hace una empresa con la misma complejidad de negocio de antes, pero ahora repartida en veinte repositorios, con más superficie de fallos y menos gente capaz de ver el sistema completo. Si tu equipo entra en una sala a decidir esto y nadie puede nombrar, con datos concretos, cuál es el cuello de botella de hoy, la respuesta correcta no es "qué arquitectura de microservicios armamos". Es quedarse en el monolito una vuelta más, y resolver primero el problema que en realidad tienen.
