Las 8 falacias de la computación distribuida cumplen 21 años: ¿qué hemos aprendido?
En 1994, Peter Deutsch formuló las "8 falacias de la computación distribuida", una lista de suposiciones erróneas que los desarrolladores suelen hacer al construir sistemas distribuidos. 21 años después, el blog de APNIC recuerda que estas falacias no solo siguen vigentes, sino que se han vuelto más relevantes con el auge de la nube, los microservicios y la computación en el borde.
Por qué importa
Cada vez que una aplicación web se cae por un error de red, un servicio de streaming se ralentiza o un sistema de pago falla, es probable que detrás haya una de estas falacias. Ignorarlas cuesta dinero, reputación y tiempo de desarrollo. En un mundo donde todo está distribuido, entender estos errores es la base para construir sistemas robustos.
Qué dice el contexto
- Las 8 falacias son: 1) la red es confiable, 2) la latencia es cero, 3) el ancho de banda es infinito, 4) la red es segura, 5) la topología no cambia, 6) hay un solo administrador, 7) el costo de transporte es cero, 8) la red es homogénea.
- El artículo de APNIC, publicado en diciembre de 2025, celebra el 21 aniversario de la lista original (1994) y analiza cómo cada falacia se manifiesta en sistemas modernos como Kubernetes, bases de datos distribuidas y APIs REST.
- La falacia más ignorada sigue siendo "la red es confiable": incluso en entornos cloud con redundancia, las particiones de red ocurren y causan caídas masivas.
- La falacia "la latencia es cero" es crítica para aplicaciones en tiempo real (videollamadas, juegos online) y suele subestimarse al diseñar arquitecturas de microservicios.
- La falacia "la red es segura" ha ganado protagonismo con el aumento de ataques a la cadena de suministro y la necesidad de cifrado extremo a extremo.
Lo que puedes hacer
- Audita tus suposiciones de red: revisa si tu código maneja correctamente timeouts, reintentos y fallos de conexión. No asumas que la red siempre responde.
- Mide la latencia real: antes de decidir una arquitectura distribuida, mide la latencia entre servicios en lugar de asumir que es despreciable. Usa herramientas como ping, traceroute o servicios de monitoreo.
- Diseña para el fallo: implementa patrones como circuit breaker, bulkhead y retry con backoff. Prueba tus sistemas bajo condiciones adversas (caídas de red, alta latencia) usando chaos engineering.
En una frase
“
21 años después, las 8 falacias de la computación distribuida siguen siendo la causa raíz de la mayoría de las caídas en sistemas modernos.
