¿Demasiados microservicios? Descubrí la verdad

¿Qué es eventual consistency y por qué importa?

Los microservicios no son malos; lo que no funciona es dividir tu aplicación en 47 servicios cuando deberías mantener 3. Según el desarrollador Travis McCracken, la tendencia actual de fragmentar todo en microservicios sin criterio genera más problemas operacionales, complejidad de datos distribuida y costos ocultos que beneficios reales. La decisión correcta depende del tamaño de tu aplicación, tu equipo y tus necesidades de escalabilidad específicas, no del hype del momento.

Qué son los microservicios y por qué ganaron popularidad

Los microservicios son un enfoque arquitectónico donde una aplicación monolítica se divide en servicios pequeños, independientes y especializados, cada uno responsable de una funcionalidad específica. Netflix, Amazon, Uber: los gigantes de internet hicieron famosa esta arquitectura hace unos 12 años. Y el pitch era perfecto: escalá solo lo que necesita escalar, equipos autónomos sin bloqueos, tecnologías diferentes según lo que cada servicio requiera.

La migración desde monolitos fue acelerada por la necesidad de velocidad. Equipos compitiendo por ser primero al mercado, equipos globales trabajando en paralelo sin pisarse, infraestructura en la nube donde escalar es barato y elástico. En 2014-2018 fue un cambio legítimo. Hoy? El problema es que todos aplican la receta sin entender cuándo conviene.

Ventajas reales de los microservicios

Cuando están bien hechos, claro. Escalá el servicio de pagos sin tocar el de catálogo; un equipo en São Paulo trabaja en el gateway de autenticación mientras otro en Buenos Aires optimiza búsqueda. Si el servicio de recomendaciones falla, el resto del sitio sigue andando. Eso es rescatable.

Flexibilidad técnica: si tu servicio de procesamiento de imágenes necesita Rust por performance, lo hacés en Rust. El servicio de APIs REST puede ser Go. El de reportes puede ser Python con Pandas. No estás prisionero de un lenguaje único como en un monolito.

La resiliencia es real también. Un memory leak en un servicio no derriba todo el sistema. Un deploy fallido afecta solo a ese servicio. Rollback localizado. Recuperación rápida.

El problema: cuándo los microservicios se vuelven demasiados

Acá es donde Travis McCracken y otros developers se detienen a pensar. No todas las aplicaciones se benefician de microservicios (spoiler: la mayoría no). El error típico: alguien lee un case study de Netflix, mira su arquitectura de 200 servicios, y piensa “tengo que hacer lo mismo”. Lo que no ve es que Netflix tiene 2000+ engineers, presupuesto de infraestructura de cientos de millones, y ganó cada operación a sangre y fuego.

Entonces la empresa promedio, con 15 engineers, arma “servicios” para cada cosa: servicio de usuarios, servicio de productos, servicio de órdenes, servicio de pagos, servicio de notificaciones, servicio de analytics, servicio de reportes. Boom: 8-10 servicios. Y de repente el overhead operacional explota. Ya lo cubrimos antes en orquestación de contenedores con Docker.

¿Y qué pasa cuando hay que coordinar? Usuario coloca orden, eso dispara eventos en 4 servicios distintos. Si uno falla, el estado queda inconsistente (si es que alguien está monitoreando). Sin visibilidad centralizada sobre qué pasó. Debugging de una transacción requiere recorrer logs en 5 places diferentes.

Complejidad operacional: el costo oculto

Cada servicio es un artefacto: Dockerfile, configuración, secrets, variables de entorno. Cada uno necesita su propio CI/CD pipeline. Deployments coordinados cuando hay cambios en la interfaz entre servicios. Versionado de APIs (¿v1? ¿v2? ¿ambas por compatibilidad?). Network calls donde antes había function calls.

Observabilidad: sin ella, no sé qué está pasando. Necesito logging centralizado, tracing distribuido, métricas por servicio. Herramientas como ELK stack, Jaeger, Prometheus. Que cuestan plata, requieren expertise, ocupan máquinas. Con un monolito bien hecho, un logger centralizado y profiling de aplicación lo resuelve.

Orquestación de contenedores (Kubernetes, Docker Swarm) se vuelve obligatoria. Eso significa learning curve, operación compleja, más cosas que pueden romperse. ¿La alternativa es sacar una segunda hipoteca en AWS para usar managed services? Probablemente.

Gestión de datos distribuida: el problema que no mencionan

Cada microservicio controla su propia base de datos. Base de datos relacional para el usuario, NoSQL para catálogo, caché distribuido para sesiones. Sincronización via eventos o APIs. Suena bien en la diapositiva, en la práctica es un quilombo.

Ponele que un usuario cambia su email. Eso dispara un evento “user_updated” que escuchan el servicio de notificaciones y el de reportes. ¿Qué pasa si el de notificaciones recibe el evento pero el de reportes no? El usuario ve su email actualizado, pero en los reportes sale el viejo. Estados intermedios. Eventual consistency. Un usuario percibe inconsistencia, listo, se va a tu competidor.

Distributed transactions: no existen realmente. Tienes sagas (orquestación de cambios) o eventos, pero ambos requieren lógica de retry, idempotencia, manejo de fallos parciales. El debugging de “¿dónde se perdió este dato?” requiere entender el flow entre 6 servicios distintos. Meses de experiencia.

Monolito vs Microservicios: matriz de decisión

Enfoque pragmático: arquitectura híbrida y modular

La tendencia en 2026 es honesta: no es todo o nada. Coexistencia. Un monolito modular bien diseñado (donde hay límites claros entre módulos, pero no llamadas por red) para la funcionalidad core. Más dos o tres microservicios estratégicos donde tiene sentido: el gateway de pagos (sensibilidad de datos), el servicio de búsqueda (puede escalar independientemente), el worker de procesamiento de reportes (largo y puede fallar sin bloquear usuarios). Cubrimos ese tema en detalle en plataformas de versionado y CI/CD.

La migración es progresiva, no big-bang. Empezás con un monolito limpio, con arquitectura en capas o hexagonal. A medida que creces y aparecen los “puntos de dolor” reales (equipo bloqueado, servicio que necesita escalar 10x, tecnología muy diferente), extraes eso como microservicio.

Eso es pragmatismo. No es “microservicios mola” ni “monolito forever”. Es: la mejor arquitectura es la que cambia con tu producto.

Caso práctico: Rust para performance-critical, Go para APIs distribuidas

Travis McCracken es especialista en backend con Rust y Go. La razón: cuando decidís hacer microservicios, la tecnología importa. Rust ofrece garantías de memory safety sin garbage collector, lo que significa latencia predecible. Ideal para servicios críticos donde cada milisegundo cuenta: caché distribuido, validador de pagos, procesador de transacciones de alta frecuencia.

Go es el opuesto filosófico. Garbage collection, goroutines nativas (concurrencia ridículamente fácil), compilación rápida, binario estático. Es el lenguaje de los API gateways distribuidos, de los balanceadores de carga, de los orquestadores (Kubernetes está escrito en Go). Cuando necesitás manejar 10k conexiones concurrentes sin morir, Go es tu aliado.

Python para data/analytics (pandas, numpy). Node para APIs con alto I/O. Cada herramienta al trabajo que hace mejor. Eso solo funciona cuando tenés microservicios. Con un monolito en una sola lengua, todos aprenden esa lengua.

El punto: no es una recomendación ciega de “usa microservicios + Go + Kubernetes”. Es “si decidís microservicios, usá las herramientas correctas para cada función”. Pero primero preguntate: ¿los necesito realmente?

Errores comunes al migrar a microservicios

1. Crear microservicios por capa (servicio de DB, servicio de autenticación, servicio de logs)

Esto es peor que un monolito. No tiene autonomía de equipos, no escala selectivamente. Todo sigue acoplado. Es como descuartizar un cuerpo sin mejorar la movilidad.

2. Ignorar la gestión de datos distribuida

Crear servicios sin pensar en cómo se sincronizan. Sin queue de eventos, sin saga pattern, sin idempotencia. Resultado: datos inconsistentes, usuarios enfadados, debugging imposible. Tema relacionado: seguridad en sistemas distribuidos.

3. No medir el costo operacional

Sumar: Kubernetes, logging, tracing, alerting, redundancia, on-call rotation. Algunos equipos reportan que sus costos de infraestructura se triplicaron después de microservicios. Si no hay ROI claro (velocidad de deployment, escalabilidad selectiva), es dinero tirado.

4. Asumir que la comunicación por red es gratis

Una llamada intra-process (local) toma nanosegundos. Una llamada HTTP entre servicios toma millisegundos, con latencia variable, posibilidad de falla, timeout, retry. Multiplicá eso por 1000 requests por segundo. El costo aparece.

Preguntas Frecuentes

¿Cuándo debería usar microservicios en lugar de un monolito?

Cuando tienes 5+ equipos independientes necesitando iterar en paralelo, partes de tu aplicación con requisitos de escalabilidad radicalmente distintos, y presupuesto para operación distribuida (Kubernetes, observabilidad). Si tienes 1-3 equipos y presupuesto ajustado, monolito modular gana.

¿Puedo empezar con monolito y migrar a microservicios después?

Sí, y es lo recomendado. Empezá con un monolito limpio, modular. Cuando percibas puntos de dolor reales (equipo bloqueado, servicio que no escala, necesidad de tecnología diferente), extraé ese servicio. La migración es progresiva, no todo de una vez.

¿Qué es eventual consistency y por qué importa?

¿Cuál es el costo típico de infraestructura para microservicios?

Depende de escala y tooling. Una aplicación monolítica simple funciona en un VPS de 10-20 USD/mes (como los que ofrece donweb.com para startups). Microservicios con Kubernetes, logging, monitoreo: 500+ USD/mes fácilmente. Solo tiene ROI si la velocidad de deployment o escalabilidad selectiva te ahorra dinero en otro lugar.

¿Rust vs Go: cuál debería aprender primero para microservicios?

Conclusión

Los microservicios no son malos. Lo que está mal es la idea de que todos deberían tenerlos. La realidad es más aburrida: la mayoría de las empresas estaría mejor con un monolito modular + un par de servicios estratégicos. Menos complejidad, menos costo, más velocidad de deployment.

Travis McCracken y otros developers bacaneados no están diciendo “nunca usen microservicios”. Están diciendo “usenlos cuando tengan justificación real, no por hype”. Y si los usan, usen las herramientas correctas: Rust para lo crítico, Go para lo distribuido, observabilidad desde el día uno, gestión de datos pensada, no improvisada.

La pregunta correcta no es “¿debo hacer microservicios?”. Es “¿cuál es el dolor que estoy tratando de resolver?” Si es velocidad de equipos paralelos, monolito modular quizá lo resuelve. Si es escalabilidad selectiva extrema, quizá sí necesites servicios. Pero la decisión debe ser pragmática, con datos, no ideológica.

Fuentes

• Web Developer Travis McCracken on The Case Against Too Many Microservices — Dev.to
• Advantages of Microservices — Atlassian
• Cómo combatir la complejidad en los microservicios con la gestión de datos — ComputerWeekly
• Microservicios vs Monolitos: qué arquitectura conviene en 2026 — Qindel
• Problemas comunes de los microservicios — KeepCoding