La historia de cómo una startup que iba viento en popa casi quebró 6 meses después de adoptar MSA

Hace poco leí un artículo que se volvió tema de conversación en blogs técnicos del extranjero, "Microservices Killed Our Startup. Monoliths Would’ve Saved Us", y quise compartir un resumen porque me pareció tan dolorosamente cierto como fácil de identificar.

Parece una muy buena "libreta de errores" que muestra lo peligroso que puede ser adoptar la tecnología más reciente de forma incondicional.

---

1. El inicio del problema: "Hagámoslo como Netflix"

• Situación: habían levantado una inversión semilla de $2.5M, los ingresos mensuales crecían 40% y tenían 50 mil usuarios. Era una startup que funcionaba muy bien con un monolito en Rails.
• Cómo empezó el problema: apareció un arquitecto líder gritando "escalabilidad (Scalability)" y propuso migrar a MSA.
• Lógica: "La estructura actual está demasiado acoplada. Mira a Netflix o Uber. Si queremos llegar a ser como ellos, tenemos que ir hacia microservicios."
• Realidad: un equipo de 4 desarrolladores y 1 DevOps decidió adoptar una arquitectura estilo Netflix.

2. Seis meses en el infierno (cronología de la adopción de MSA)

[Mes 1: luna de miel]

• Separaron con éxito el servicio de notificaciones. "¿Ven? ¡Funciona bien!", decían mientras celebraban.
• Pero empezaron las señales de advertencia: más tiempo de despliegue, más repositorios, etc.

[Meses 2~3: comienzan las grietas]

• Separaron el servicio de facturación (Billing). El problema es que estaba entrelazado con usuarios, inventario y pedidos.
• Resultado: la latencia de red hizo que el tiempo de respuesta pasara de 200ms a 800ms. Si un servicio caía, provocaba fallas en cadena y terminaba cayéndose todo.

[Meses 4~5: la pesadilla de las transacciones distribuidas]

• Lo que en el monolito se resolvía con una sola transacción de base de datos, en un entorno distribuido los obligó incluso a introducir el patrón Saga.
• Bajaba el inventario, pero fallaba el cobro, el rollback se enredaba... y la inconsistencia de datos disparó las consultas a soporte.
• Agregar una sola columna simple implicaba tocar 6 servicios, así que algo de 2 horas terminaba tomando 3 días.

[Mes 6: colapso del equipo]

• Los desarrolladores pasaban todo su tiempo administrando infraestructura en vez de construir funcionalidades.
• El costo de infraestructura pasó de $3,000 a $12,000 (se cuadruplicó).
• Renunció un desarrollador clave ("Vine a crear producto, no a pasarme el día entero picándole a Kubernetes").

3. La decisión: "No somos Netflix"

El arquitecto seguía insistiendo en que debían "adoptar un Service Mesh y sumar más herramientas de monitoreo", pero el autor finalmente explotó.

"¡No somos Netflix! ¡Netflix tiene 500 ingenieros y nosotros somos 4!"

Al final, el arquitecto se fue de la empresa y el equipo decidió volver al monolito (Rollback).

4. Regreso al monolito, y resurrección

• Durante 8 semanas, volvieron a unir el código en un monolito.
• Resultado:
• Se recuperó la velocidad de lanzamiento de funcionalidades (de 4 al mes → 20 al mes)
• El tiempo de respuesta se estabilizó en 220ms
• Bajaron los costos de infraestructura
• Y, sobre todo, subió la felicidad de los desarrolladores

5. Lecciones clave (la conclusión del artículo)

1. MSA no es una herramienta para resolver un 'problema técnico', sino un 'problema organizacional'.

• Se usa cuando hay más de 50 desarrolladores que empiezan a estorbarse entre sí, o cuando los ciclos de despliegue son demasiado distintos entre equipos.

2. Netflix/Google no son tu modelo a seguir.

• Ellos también comenzaron con un monolito. Cambiaron porque crecieron; no empezaron así desde el día uno.

3. La complejidad es un impuesto.

• Cada vez que aumenta el número de servicios, el costo de administrarlos crece de forma compuesta.

4. Las llamadas de red no son gratis.

• Una llamada de función en memoria (nanosegundos) y una llamada por red (milisegundos) juegan en ligas totalmente distintas.

---

Resumen en una línea:
"El monolito no es el enemigo. El enemigo es una mala arquitectura. Si tu equipo es de 4 personas, por favor simplemente usa un monolito."

[ahwjdekf]

Bueno. Ahora vienen en masa los fanáticos religiosos de MSA.

[aer0700]

Es cierto que las llamadas de red no son gratis. Una llamada a función y una llamada a una API claramente son cosas distintas.

[bungker]

"Vine a crear producto, no a pasarme todo el día metido en Kubernetes" —> probablemente es una de las cosas más idiotas que he escuchado

[hohemian]

¿Por qué? Creo que tiene sentido decir eso cuando están haciendo k8s por hacer k8s, como si k8s fuera el objetivo.

[roxie]

Me gustan tanto los comentarios de bungker que los voy abriendo uno por uno, pero con este no logro identificarme, hmm. ¿Podrías dar un poco más de contexto?

[passerby]

Es una publicación sobre IA sin sustancia; por eso últimamente casi no leo Medium.

[mhj5730]

Si es un servicio hecho por 4 personas, parece que realmente no habría motivo para dividirlo con MSA.

[moderato]

Para implementar MSA, la organización también tiene que alinearse con MSA...

[ifmkl]

Creo que el punto que quería transmitir el punto 4 está en el resumen de abajo. Y, en general, el contenido en sí me parece bastante acertado.

[bsh998]

Mmm... algo se siente raro aquí.
Creo que este texto fue escrito con IA.

[baeba]

Yo también lo siento mucho últimamente..
Me imagino que muchos textos de blogs se están escribiendo
con la experiencia propia del autor + la ayuda de la IA.
Es que muchos están tan bien estructurados y son tan fáciles de leer.

[bsh998]

Lo que quería decir es que me parece una opinión muy generada por IA y sin referencias, así que preferiría que no compartieran este tipo de textos.

[baeba]

Es una publicación subida a Hacker News. La mayoría de los textos que publico son contenidos que aparecieron en Hacker News.

https://news.ycombinator.com/item?id=46469845

Como mencionaste... creo que sí debería incluir la referencia de Hacker News.

[baeba]

1) Dudas sobre la credibilidad del texto: huele a marketing / contenido generado por IA

Punto clave

• “Esto está demasiado bien armado como una fábula con moraleja” → da la impresión de estar optimizado como el tipo de ‘obra moralizante’ que le gusta a HN
• El texto está lleno de enlaces a material de pago, así que hubo muchos comentarios de “¿al final no es solo un texto de ventas?”
• También señalaron que el estilo, con listas por todos lados y emojis, parece una señal de “AI slop” (contenido de IA hecho al aventón)

Cita demoledora (traducción)

“Parece que todo el texto existe solo para venderte los recursos enlazados. Y se siente como AI slop con tantas listas.”
(Original: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)

Resumen en una línea

• Antes incluso de discutir si el contenido está bien o mal, la primera reacción fue: huele demasiado a venta + a IA.

---

2) Crítica al liderazgo / al arquitecto: el problema no era la tecnología, sino la ‘estructura de toma de decisiones’

Punto clave

• Mucha gente reaccionó con un “¿arquitecto para un equipo de 4 personas?” como señal de que algo ya venía mal desde ahí
• En particular, hubo una visión muy fuerte de que un arquitecto que no programa / un rol de DevOps separado crea cuellos de botella y está más orientado al CV que al producto
• El tono general fue que lo que casi hundió a la empresa no fueron los microservicios, sino “una estructura donde nadie se hace realmente responsable de desplegar, operar y arreglar las cosas”

Cita fulminante (traducción)

“Los arquitectos cuyo trabajo es definir ‘reglas’ y ‘patrones’ sin implementar nada casi siempre son una pésima idea. Mejor enfóquense en sacar el producto... Si alguien que no va a escribir ni 10 líneas de código monopoliza las decisiones, van a fracasar.”
(Original: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)

Resumen en una línea

• Hubo bastante apoyo a la idea de que el problema no era MSA, sino un diseño de roles con poder de decisión pero sin responsabilidad real.

---

3) Perspectiva de negocio: ¿de verdad la causa del fracaso de la startup fue MSA?

Punto clave

• También hubo comentarios que directamente no compraron el encuadre de “fracasamos por la arquitectura”
• La idea central: si PMF / la demanda / el lock-in de clientes es débil, cualquier stack puede fracasar
• En especial, cuestionaron detalles como “¿los clientes se van de inmediato porque el producto estuvo dos días más lento?” para insinuar que tal vez el valor real del producto ya era débil desde antes
• Además, marcaron una contradicción interna del texto: dice “MSA casi mata a la startup”, pero la conclusión es “¿entonces sobrevivió?” → eso hizo sospechar de una narrativa exagerada

Cita demoledora (traducción)

“Estoy bastante seguro de que lo que mató a su startup fue hacer un producto que la gente no quería. Esto es tan absurdo como decir que usar Python en vez de Go mató a su startup...”
(Original: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)

Resumen en una línea

• Existió claramente la postura de que la arquitectura es solo una excusa y que la causa real puede haber sido mercado / producto / flujo de caja.

---

4) Insight técnico: consejos útiles basados en experiencia sobre monolito vs MSA

Punto clave

• “MSA tiene un impuesto de costo fijo (complejidad operativa)” → hubo muchos testimonios de que eso puede ser letal para equipos pequeños
• Palabras clave: Premature distribution (distribución prematura), monolito modular / modulith, y “las fronteras (boundary) hay que ganárselas”
• También se plantearon de forma realista las condiciones en las que MSA sí empieza a tener sentido: cuando el tamaño del equipo crece y ya aparecen de verdad choques, problemas de despliegue y fricción organizacional
• En cambio, para problemas de rendimiento o escalabilidad, varios aconsejaron que normalmente no hay que pensar primero en “resolverlo con MSA”, sino en algoritmos, cuellos de botella, sharding y particionamiento

Cita fulminante (traducción)

“Lo que mató a la startup no fueron los microservicios, sino la ‘distribución prematura’. Fragmentaron el sistema antes de que existieran fronteras reales, y solo pagaron el costo de latencia y coordinación. Hay que empezar con un monolito modular, ganarse esas fronteras y recién después extraer servicios.”
(Original: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)

Resumen en una línea

• La lección con la que más conectó la comunidad fue esta:
  “Empieza con un monolito y separa servicios solo cuando las fronteras aparezcan de forma natural.”

---

Evaluación general de la comunidad en una frase

La mayoría estuvo de acuerdo con “no somos Netflix”, pero al mismo tiempo también sospechó que este texto podría ser una narrativa que vende la enfermedad de querer ser Netflix (= marketing / IA).