Tengo que empezar con una aclaración honesta, porque hace a cómo escribí este post. Cuando se cayó medio internet dos veces en pocas semanas, sentí lo que seguramente sintieron muchos: una mezcla de fascinación y de “¿otra vez?”. Pero también sentí algo más incómodo: que no terminaba de entender, en detalle, qué había fallado. Los informes técnicos que publicaron AWS y Cloudflare son excelentes, pero también densos, llenos de detalles de infraestructura que no son mi especialidad. Así que hice algo que cada vez hago más: me apoyé en la IA para masticarlos. Le pasé los postmortems, le pedí que me explicara los mecanismos de falla en términos que pudiera discutir, que me ayudara a separar el detalle técnico del patrón de fondo. Para poder llegar yo a una opinión sin pretender hacer una pericia en infraestructura para la cual no tengo el conocimiento suficiente. Lo que sigue son mis conclusiones, pero el camino para entender lo técnico lo recorrí acompañado. Y, mirándolo bien, eso también es parte de lo que vengo diciendo todo el año sobre cómo usar estas herramientas con criterio.
Lo que pasó, sin pretender ser experto#
Repaso los dos episodios en términos simples, que es como los entendí. El 20 de octubre, AWS sufrió una caída enorme en su región de Virginia, US-EAST-1, que es una de las más importantes del mundo y de la que cuelgan, de forma directa o indirecta, una cantidad asombrosa de servicios. Según el informe que publicó la propia empresa, el origen fue una condición de carrera —una situación en la que dos procesos automáticos que debían coordinarse pisaron uno el trabajo del otro— dentro del sistema que gestiona el DNS de su base de datos DynamoDB. El resultado, contado en criollo, fue que quedó vacío un registro que sirve para que los sistemas encuentren ese servicio. Como tantas otras cosas dependían de él, la falla se propagó en cascada durante unas quince horas y se llevó puesta a media internet: aplicaciones, juegos, billeteras, hasta pedidos de comida rápida.
El 18 de noviembre, apenas unas semanas después, le tocó a Cloudflare, que es esa capa invisible por la que pasa una porción gigantesca del tráfico web del mundo. Acá el origen fue distinto en los detalles pero, como veremos, sospechosamente parecido en su forma. Un cambio de permisos en una base de datos hizo que una consulta empezara a devolver filas duplicadas. Eso, a su vez, hizo que un archivo de configuración que usa su sistema de detección de bots —el que decide si quien visita un sitio es una persona o un robot— duplicara su tamaño. Y ese archivo, más grande de lo previsto, superó un límite fijo que estaba grabado en el software que enruta el tráfico. Al pasar ese límite, el sistema entró en pánico y empezó a fallar. Como ese archivo se propaga a toda la red cada pocos minutos, el problema se replicó por todos lados casi simultáneamente, y durante varias horas una parte enorme de la web devolvió errores.
No voy a fingir que entiendo cada matiz técnico de estos mecanismos; no es lo mío, y para eso están los ingenieros de esas empresas, que además escribieron informes muy buenos. Pero no hace falta ser experto en infraestructura para ver lo que tienen en común. Y es ahí, en lo que comparten, donde está lo que de verdad me interesa.
El patrón que se repite#
Cuando puse los dos casos uno al lado del otro —con ayuda, lo dije, de un análisis que hice con IA para no perderme en la maleza técnica— el patrón saltó a la vista, y resultó ser exactamente el mismo que ya había descrito hace más de un año hablando de la caída asociada a CrowdStrike. Tres incidentes enormes, de tres empresas distintas, separados en el tiempo, y los tres responden a la misma estructura profunda.
Primero: ninguno fue un ataque. No hubo hackers, no hubo malicia, no hubo enemigo. Los tres fueron errores internos, cambios propios que salieron mal. Esto ya lo había señalado con CrowdStrike y lo vuelvo a subrayar porque va contra la intuición: cuando pensamos en que internet se cae, imaginamos villanos, y la realidad es que el villano más frecuente somos nosotros mismos, con un cambio mal calculado.
Segundo, y esto es lo más revelador: en los tres casos, un cambio pequeño se propagó demasiado lejos. Una actualización de contenido en CrowdStrike. Un registro DNS que quedó vacío en AWS. Un archivo de configuración que creció de más en Cloudflare. Ninguna de esas cosas, en sí misma, es catastrófica. Lo catastrófico fue que no había nada que frenara su propagación. El error chiquito viajó, sin diques, hasta convertirse en un apagón global. La fragilidad no estuvo en el tamaño del error, sino en la ausencia de límites a su propagación.
Y tercero: en los tres, el detalle que falló era algo que todos asumían correcto y que nadie estaba mirando. Un registro DNS que siempre había estado bien. Un límite de tamaño que parecía holgado. Una actualización que siempre se había aplicado sin problema. Piezas invisibles, dadas por sentadas, hasta el día que dejaron de comportarse como esperábamos. Es, otra vez, la historia de las dependencias invisibles sobre la que escribí en abril: no se rompe lo que vigilamos, se rompe lo que dejamos de mirar porque nunca nos había fallado.
“Radio de explosión”: una idea que conviene incorporar#
Hay un concepto que aparece en estos análisis y que vale oro para cualquiera que diseñe sistemas: el radio de explosión. La idea es simple y visual. Cuando algo falla, ¿hasta dónde llega el daño? ¿Queda contenido en una pieza, o se expande y arrastra todo lo que toca? Un buen diseño no es uno donde nada falla nunca —eso no existe— sino uno donde, cuando algo falla, el daño queda acotado, con paredes que impiden que el fuego de una habitación queme la casa entera.
Lo que tienen en común los tres apagones es que el radio de explosión fue inmenso. Un problema en una región de AWS no debería poder afectar al mundo entero, pero lo hizo, porque demasiadas cosas dependían de esa región específica para funciones críticas. Un archivo de configuración mal generado en Cloudflare no debería poder tumbar la red completa, pero lo hizo, porque se propagaba a todos lados a la vez sin etapas ni frenos. En los dos casos, faltaron las paredes. Faltó el diseño que dice “si esto falla, que falle solo, no que se lleve todo puesto”. Y esto conecta con algo que vengo repitiendo: la resiliencia no consiste en evitar el fallo, sino en diseñar para que el fallo no se propague. Cuando hablé de CrowdStrike lo dije con otras palabras; ver el mismo principio violado dos veces más, en pocas semanas, lo vuelve casi una ley.
La paradoja de la página que también se cae#
Hay un detalle de estos episodios que me llamó la atención y que toca un tema muy de mi mundo: la comunicación durante la crisis. Cuando un proveedor gigante se cae, miles de equipos como el mío quedan a ciegas, mirando un sistema que no responde y tratando de entender si el problema es nuestro o de afuera. Y lo primero que hacemos es correr a la página de estado del proveedor, esa que debería decirnos “sí, somos nosotros, estamos en eso”. El problema es que, en incidentes de esta magnitud, a veces esa misma página o los canales para comunicarla dependen de la infraestructura que se cayó. Te quedás sin servicio y, además, sin la información para saber qué está pasando con el servicio.
Es una paradoja que me parece profundamente instructiva, más allá de los gigantes: nuestros sistemas de observación y comunicación de incidentes no pueden depender de la misma capa que están vigilando. Si el tablero que me avisa que algo se rompió se rompe junto con todo lo demás, no tengo tablero, tengo un adorno. Lo mismo vale para la comunicación hacia adentro y hacia afuera: si para avisarle al equipo o a mis clientes que hay un incidente dependo de una herramienta que también está caída, me quedé mudo en el peor momento. Esto lo había mencionado de pasada cuando escribí sobre CrowdStrike, pero verlo repetirse a esta escala lo vuelve una lección dura: la resiliencia no es solo que el sistema aguante, es también que mi capacidad de entender y comunicar lo que pasa sobreviva a la propia caída.
Y acá hay algo que sí está a mi alcance, aunque no sea AWS. Puedo asegurarme de que mi monitoreo no viva enteramente sobre la infraestructura que monitorea. Puedo tener un canal de comunicación de emergencia que no dependa de las mismas herramientas de todos los días. Puedo decidir de antemano quién comunica qué, a quién, y por qué medio cuando todo lo habitual no está disponible. Nada de eso evita el apagón, pero cambia por completo cómo lo transito: la diferencia entre un equipo que durante el incidente sabe qué pasa y puede avisar, y uno que está tan a oscuras como sus usuarios, esperando que la página de estado de un tercero vuelva a la vida para enterarse de su propia situación.
Algo que noté al analizar estos casos, y que me reconcilia con varios de los temas que toqué este año, es el rol de la velocidad. Estos sistemas están diseñados para desplegar cambios rápido, propagar configuraciones en minutos, actualizarse constantemente. Esa velocidad es lo que los hace potentes y modernos. Pero es también, exactamente, lo que amplificó las fallas. El archivo malo de Cloudflare se propagó a toda la red en minutos justamente porque el sistema está optimizado para propagar rápido. La velocidad que es una virtud en el día a día se transformó, el día del incidente, en el acelerador del desastre.
Vi a algunos analistas conectar esto con la cultura actual de shipear features a toda velocidad, e incluso con el espíritu del vibe coding del que hablé en marzo y en julio: priorizar la rapidez de entrega por encima de la robustez. No quiero forzar la analogía, porque estas son empresas con ingeniería de primerísimo nivel y procesos serios, no proyectos vibe-codeados un fin de semana. Pero el principio de fondo resuena con todo lo que vengo pensando: la velocidad sin frenos tiene un costo, y ese costo no aparece en el día a día, aparece de golpe el día que algo sale mal. Es la misma idea que planteé con el código generado por IA y con la elección de modelos: ir rápido no es gratis, simplemente la cuenta llega más tarde y toda junta.
Lo que de verdad me preocupa: no aprendemos entre apagón y apagón#
Acá está, creo, la reflexión más incómoda, y la que justifica juntar los dos casos en un solo post en vez de comentarlos por separado. Hace más de un año escribí sobre CrowdStrike y dije, con cierta esperanza, que ojalá nos dejara conciencia. Bueno: pasó CrowdStrike, pasó AWS, pasó Cloudflare, y el patrón es idéntico. No es que no sepamos qué falla; lo sabemos, está escrito en cada postmortem. Es que, como industria, no terminamos de cambiar las condiciones que lo hacen posible. Seguimos concentrando enormes cantidades de servicios críticos en unos pocos proveedores. Seguimos asumiendo que esas piezas gigantes no se van a caer. Seguimos sin diseñar para contener el radio de explosión.
Y no lo digo desde la superioridad, porque caigo en lo mismo. Cuando elijo dónde alojar un sistema, voy a los proveedores grandes, como todos, porque son confiables, baratos y cómodos. La concentración no es un capricho; es una consecuencia racional de que esos proveedores son, casi siempre, la mejor opción. El problema es colectivo: cada decisión individual de concentrarse es razonable, pero la suma de todas nos deja un internet donde la falla de una empresa puede apagar medio mundo. Es una tragedia de los comunes, pero con servidores. Nadie decide construir un sistema frágil; lo construimos entre todos, una decisión cómoda a la vez.
“Entonces diversifiquemos todo”, y por qué no es tan simple#
La respuesta refleja a todo esto suele ser: bueno, no pongamos todos los huevos en la misma canasta, repartamos entre varios proveedores. Y suena impecable hasta que uno lo piensa en serio. Diversificar la infraestructura —correr en dos nubes, tener proveedores alternativos para todo— es muchísimo más caro, más complejo y más lento de operar. Cada proveedor tiene sus particularidades, y mantener un sistema que funcione idéntico en dos lugares a la vez suele duplicar el trabajo y multiplicar los puntos donde algo puede salir mal. A veces, la complejidad que agregás para protegerte de una caída introduce más fallas de las que evita. La cura puede ser peor que la enfermedad.
Por eso desconfío de la receta fácil del “diversificá todo”. Me parece más honesto pensarlo como una decisión de criterio, caso por caso, igual que cuando hablé de elegir el modelo de IA adecuado en vez del más grande por defecto. La pregunta no es “¿multi-cloud sí o no?” como dogma, sino “¿qué partes de mi sistema son tan críticas que justifican el costo de tener una alternativa, y cuáles pueden tolerar unas horas de caída sin que el mundo se termine?”. No todo merece el mismo nivel de protección, porque protegerlo todo por igual es la forma más segura de no poder pagar la protección de nada. La diversificación tiene sentido como la opción de poder fallar hacia otro lado para lo que de verdad no puede parar, no como un mandamiento de correr todo en paralelo por las dudas.
Y hay una trampa adicional que conviene nombrar: muchas veces creemos que diversificamos y no es cierto. Usamos dos proveedores distintos que, sin que lo sepamos, dependen por debajo de la misma pieza de infraestructura, del mismo DNS, del mismo punto de concentración. La diversificación de la superficie no garantiza la diversificación del fondo. Volvemos, otra vez, a las dependencias invisibles: no se puede diversificar de verdad lo que no se conoce, y para saber de qué dependemos realmente hay que haber hecho antes el trabajo incómodo de mapearlo.
Una objeción honesta a todo esto: yo no opero la infraestructura de medio internet. ¿Qué me llevo, como alguien que conduce un equipo de tamaño normal, de una falla en una de las empresas más grandes del planeta? Bastante, en realidad, si traduzco las lecciones a mi escala.
Me llevo, primero, la pregunta por mis propias dependencias críticas, que es la misma que me hice en abril pero ahora con más urgencia: si mi proveedor principal se cae quince horas, como le pasó a los clientes de AWS, ¿qué hago? ¿Tengo siquiera pensada esa respuesta, o asumo que no va a pasar? Me llevo, segundo, la idea del radio de explosión aplicada a lo mío: cuando algo en mi sistema falla, ¿queda contenido o se propaga? ¿Tengo paredes, o un error chico puede llevarse todo? Y me llevo, tercero, una dosis de humildad: si a empresas con los mejores ingenieros del mundo y recursos infinitos les pasa esto, mi sistema no es inmune por ser más chico. Al contrario, probablemente tengo menos defensas. La diferencia es que mi apagón no sale en las noticias, pero a mis usuarios les duele igual.
No tengo una solución mágica, y desconfío de quien la ofrezca. La resiliencia total es imposible y carísima. Pero hay un punto intermedio entre la paranoia paralizante y la negación cómoda, y vive en preguntas que conviene hacerse en frío, antes del incidente: qué pasa si esto se cae, hasta dónde llega el daño, cómo me entero, cómo me recupero, qué puedo contener. No hace falta resolverlas todas. Hace falta, al menos, habérselas hecho.
Lo que me queda, después de tres apagones#
Si junto los tres episodios —CrowdStrike el año pasado, AWS y Cloudflare este— la conclusión que me queda no es técnica, porque lo técnico no es mi fuerte y además cambia con cada caso. Es casi filosófica, y tiene que ver con cómo nos paramos frente a los sistemas que construimos. Vivimos sobre una infraestructura cada vez más potente, más rápida y más concentrada, y esa misma potencia que tanto nos sirve es la que, cuando falla, falla en grande. No es un defecto que se pueda eliminar con más tecnología; es una característica del tipo de mundo que construimos, donde la eficiencia y la concentración van de la mano de la fragilidad.
La madurez, entonces, no está en pretender que estos apagones no van a pasar —van a seguir pasando, es matemático— sino en dejar de sorprendernos cada vez como si fuera la primera, y empezar a diseñar, en nuestra escala, asumiendo que el fallo es parte del paisaje. Diseñar para contener, no solo para funcionar. Y, sobre todo, tener la honestidad de mirar nuestras propias dependencias antes de que un martes cualquiera nos obliguen a mirarlas a las apuradas.
Les dejo una pregunta para llevarse, que es casi la misma que dejé hace un año pero que ahora pesa más, porque ya van tres. Cuando lean la noticia del próximo gran apagón —y va a haber uno, seguro— ¿lo van a vivir como una sorpresa indignante, “cómo puede ser que se caigan”, o como lo que en realidad es: el recordatorio previsible de una fragilidad que conocemos, que está documentada, y que seguimos eligiendo no enfrentar mientras todo, casi siempre, funcione? Porque la diferencia entre indignarse y prepararse es, al final, la única que está bajo nuestro control.
Fuentes consultadas#
- Amazon Web Services, “Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region”, postmortem publicado el 23 de octubre de 2025.
- Cloudflare, “Cloudflare outage on November 18, 2025”, 18 de noviembre de 2025.
- The Register, “A single DNS race condition brought AWS to its knees”, 23 de octubre de 2025.