Microservicios vs. Monolito: Qué Aprender de Amazon y Netflix
En marzo de 2026, un video publicado en YouTube generó un debate intenso en la comunidad de ingeniería de software. El título lo dice todo: "The Contradiction: Amazon moved back to a monolith while Netflix runs 700+ microservices".
Dos de las empresas tecnológicas más admiradas del mundo tomaron decisiones arquitectónicas opuestas. Y ambas dicen que fue la decisión correcta.
¿Cómo es posible? ¿Y qué significa esto para las empresas en LATAM que están decidiendo hoy cómo construir su sistema?
→ Puedes ver el video original en inglés aquí: Microservices at Scale: Engineering Debt and System Complexity
La historia de Netflix: cuando el monolito colapsó
Netflix comenzó como un monolito. Una sola aplicación Java corriendo sobre bases de datos Oracle. Era 2008 y funcionaba bien hasta que dejó de funcionar.
Una corrupción catastrófica de base de datos dejó el servicio completamente caído durante tres días. El problema no fue solo técnico: fue arquitectónico. En un monolito, un error en cualquier parte puede tumbar todo el sistema.
La respuesta de Netflix fue radical: un viaje de siete años para descomponer su monolito en cientos de microservicios, lo que requirió cambios fundamentales no solo en la arquitectura técnica, sino en la estructura organizacional, las prácticas de desarrollo y los procesos operativos.
El resultado: hoy Netflix opera más de 700 microservicios que manejan más de 15 mil millones de llamadas a API diariamente en más de 190 países.
Cada servicio es independiente. El equipo de recomendaciones puede hacer deploy sin tocar el equipo de pagos. El servicio de streaming puede escalar independientemente del servicio de perfiles. Netflix puede aumentar la capacidad de un servicio específico sin escalar el sistema completo, pagando solo por los recursos que usa.
La historia de Amazon Prime Video: cuando los microservicios se volvieron el problema
En 2023, el equipo de ingeniería de Amazon Prime Video publicó algo que nadie esperaba: un artículo explicando por qué habían abandonado su arquitectura de microservicios distribuidos y vuelto a un monolito.
Amazon Prime Video describió cómo un sistema distribuido que gestionaba el monitoreo de video en vivo se estaba volviendo ineficiente y costoso. Al consolidar sus microservicios en un monolito único, redujeron el costo de infraestructura en más del 90% y mejoraron significativamente el rendimiento.
No fue un fracaso. Fue una decisión de ingeniería deliberada basada en datos reales: el sistema distribuido generaba más latencia de red, más overhead operativo y más costo del que justificaba su complejidad. La arquitectura correcta en el año 1 no era la correcta en el año 5.
La contradicción que no es una contradicción
La premisa del video es provocadora, pero la respuesta es más matizada: Netflix y Amazon no tomaron decisiones opuestas. Tomaron decisiones correctas para contextos completamente diferentes.
Netflix tiene más de 30 equipos de ingeniería trabajando en paralelo, cada uno responsable de un dominio específico del producto. Sus microservicios no son solo una decisión técnica son una decisión organizacional. La arquitectura de microservicios permitió a Netflix que ingenieros desarrollaran, probaran y desplegaran servicios de forma independiente, sin tener que esperar a que los demás terminaran. Con ese tamaño de organización, el monolito sería el problema.
El sistema de monitoreo de Amazon Prime Video que volvió al monolito era completamente diferente: un sistema específico, con un equipo pequeño, donde la coordinación entre servicios distribuidos generaba más problemas de los que resolvía.
La lección no es "los microservicios son mejores" ni "el monolito es mejor". La lección es que la arquitectura correcta depende del problema, el equipo y el momento.
El costo real de los microservicios que nadie menciona en el pitch de ventas
El video aborda con honestidad algo que pocas empresas de software reconocen ante sus clientes: los microservicios tienen un costo de complejidad que no siempre está justificado.
Los microservicios introducen desafíos inherentes de sistemas distribuidos. Una sola solicitud de usuario puede abarcar múltiples servicios, creando dependencias en cascada que son más difíciles de depurar, monitorear y asegurar. Lo que antes era una simple llamada a función se convierte en una solicitud HTTP con latencia de red potencial, problemas de serialización y puntos de falla.
En el video, esto se visualiza con claridad: un codebase que antes tenía 5ms de latencia interna ahora tiene que pasar por la red para llamar a un deploy unit separado y esa latencia se multiplica con cada servicio adicional en la cadena.
Además, los microservicios frecuentemente exigen capacidades avanzadas de infraestructura. Pipelines de integración continua, plataformas de orquestación de contenedores como Kubernetes, herramientas de service discovery, logging distribuido y frameworks de tracing se vuelven esenciales solo para mantener el sistema funcionando.
Para una empresa sin un equipo DevOps maduro que es la realidad de la mayoría de empresas en LATAM esta complejidad operativa puede ralentizar el desarrollo en lugar de acelerarlo.
El patrón que las empresas exitosas tienen en común
Estudiando los casos de Netflix, Amazon, Uber y Spotify, emerge un patrón claro que el video documenta:
Todas empezaron con un monolito.
Después de estudiar cómo comenzaron las empresas exitosas, se observa que todas comenzaron con monolitos. No porque no supieran mejor sino porque los monolitos tienen ventajas reales: simplicidad, deployment único sin orquestación compleja, debugging directo cuando algo falla, y eficiencia de recursos a pequeña escala.
La transición a microservicios llegó cuando el monolito se convirtió en un cuello de botella real no cuando alguien leyó un artículo sobre microservicios y decidió que sonaban más moderno.
Los microservicios no son un destino, son una herramienta. La arquitectura correcta depende de factores como el tamaño del equipo, la complejidad del sistema, los límites del dominio y la madurez operacional.
¿Qué significa esto para tu empresa en LATAM?
La mayoría de proyectos en América Latina no son Netflix. No tienen 30 equipos de ingeniería ni 700 servicios que gestionar. Y sin embargo, muchas agencias venden microservicios como el estándar de oro de la arquitectura moderna sin mencionar el costo real que implican.
En Ab4cus, nuestra posición es clara y está documentada en nuestro enfoque de arquitectura:
Para la mayoría de proyectos en LATAM, el monolito modular es la decisión correcta.
No el monolito caótico sin estructura sino un monolito organizado con Domain-Driven Design: bounded contexts bien definidos, schemas de datos separados por dominio, contratos de API internos claros. Un sistema que tiene la disciplina interna de los microservicios sin la complejidad operativa de la red distribuida.
Esta arquitectura tiene tres ventajas concretas para proyectos en etapa de crecimiento:
- Se puede extraer en servicios independientes cuando el negocio lo justifique el código ya está organizado por dominios, el paso a microservicios es evolutivo, no una reescritura
- No requiere un equipo DevOps dedicado desde el día uno un equipo pequeño puede operar y mantener el sistema sin Kubernetes, service mesh ni distributed tracing
- La latencia es interna, no de red las llamadas entre módulos son function calls, no HTTP requests. Sin overhead de serialización, sin puntos adicionales de falla
Cuándo sí tiene sentido hablar de microservicios en LATAM
No descartamos los microservicios los usamos cuando el problema lo justifica. Los criterios concretos:
- El equipo tiene más de 15 desarrolladores trabajando en paralelo en dominios distintos
- Hay componentes con requerimientos de escala radicalmente diferentes (un módulo procesa millones de eventos por hora, otro procesa decenas por día)
- Existe un equipo DevOps dedicado con experiencia en Kubernetes y observabilidad distribuida
- El negocio justifica el overhead operativo adicional con ahorros en escala de infraestructura
Si ninguna de esas condiciones se cumple hoy, un monolito modular bien construido es más rápido de entregar, más barato de operar y más fácil de evolucionar.
La deuda técnica que nadie ve en la propuesta inicial
El video introduce un concepto clave que merece atención: engineering debt la deuda técnica que acumula una arquitectura distribuida mal aplicada.
No es solo el costo de los servidores. Es el costo del tiempo que el equipo invierte en depurar llamadas entre servicios en lugar de construir funcionalidades. Es el costo de mantener contratos de API entre 15 servicios cuando el negocio cambia de dirección. Es el costo de reclutar desarrolladores que entiendan la infraestructura de orquestación que nadie documentó correctamente.
Segment (ahora parte de Twilio) encontró que su arquitectura de microservicios se volvió difícil de gestionar a escala. La productividad de ingeniería declinó, con equipos gastando más tiempo depurando problemas de comunicación entre servicios que entregando funcionalidades. Su solución fue reconstruir la funcionalidad central en un servicio monolítico, lo que devolvió predictibilidad y mejoró el rendimiento.
Esta es la historia que no aparece en los pitches de ventas de las agencias que venden microservicios como solución universal.
Lo que la arquitectura correcta realmente garantiza
La discusión entre microservicios y monolito es, en el fondo, una discusión sobre algo más profundo: la arquitectura no es un objetivo en sí mismo es el medio para que el sistema pueda cambiar cuando el negocio lo necesite.
Un sistema con arquitectura bien diseñada permite agregar funcionalidades sin romper lo existente, escalar los componentes que lo necesitan sin escalar todo, y cambiar de tecnología en un módulo sin reescribir los otros.
Eso aplica tanto a un monolito modular como a microservicios correctamente implementados. La diferencia está en elegir la complejidad correcta para el momento correcto.
Si quiere entender qué arquitectura tiene sentido para su proyecto específico y cuánto costaría construirlo correctamente lea nuestro artículo sobre arquitectura de software o use la calculadora para tener un primer estimado:
→ Arquitectura de software: la decisión que nadie explica y que determina si tu sistema sobrevive
→ Calcular el costo de mi proyecto con arquitectura correcta
Video original en inglés: Microservices at Scale: Engineering Debt and System Complexity — publicado el 17 de marzo de 2026.
0 Comentarios