El incidente de Cloudflare del 18 de noviembre de 2023, aunque no se detalla completamente en el artículo, se centra en la decisión de diseño de usar unwrap en Rust, lo que llevó a un fallo del programa en lugar de una degradación controlada. La causa raíz subyacente no es un fallo técnico per se, sino una decisión de diseño de software que no consideró adecuadamente las implicaciones globales del manejo de errores. El unwrap es una operación que asume que una operación Result siempre tendrá éxito, y si no, provoca un pánico (crash) en el programa. En un sistema distribuido a escala de hyperscaler, un fallo de proceso no es intrínsecamente malo si es aislado y el sistema puede recuperarse rápidamente, pero se convierte en un problema si los fallos son correlacionados o si la tasa de fallos excede la capacidad de recuperación del sistema.

La cascada de fallo, aunque no explícitamente descrita para el incidente de Cloudflare, se infiere que la decisión de "crash the program" no fue apropiada para el contexto global del sistema, lo que llevó a una interrupción más amplia de lo deseado. Las salvaguardas fallaron porque la estrategia de manejo de errores fue vista como una propiedad local del componente, en lugar de una propiedad global del sistema. Esto significa que la resiliencia del sistema no fue diseñada para absorber la tasa o el tipo de fallos que este unwrap podría generar en un entorno de producción. La falta de una estrategia de manejo de errores a nivel de sistema que considerara la correlación de fallos, la capacidad de manejo en capas superiores y la posibilidad de continuar de manera significativa, contribuyó a la magnitud del incidente.

El artículo enfatiza que el manejo de errores no es una propiedad local, sino global del sistema. La idoneidad de un assert o unwrap depende de si los fallos están correlacionados, si pueden ser manejados por una capa superior (ej. un balanceador de carga reemplazando una instancia fallida) y si es posible continuar de manera significativa con la lógica de negocio. En el caso de Cloudflare, la implicación es que la decisión de fallar no cumplió con uno o más de estos principios, lo que llevó a un impacto mayor. La lección principal es que las decisiones de manejo de errores deben ser parte integral del diseño arquitectónico desde el principio, considerando el "blast radius" y la resiliencia general del sistema.