Las caídas no son una excepción, son un dato de diseño
Todo sistema falla. Un proveedor cloud tiene una interrupción regional, un despliegue rompe una dependencia, una base de datos se satura. La pregunta relevante no es si va a pasar, sino qué hace tu arquitectura en los primeros minutos después de que pasa. Ahí se juega la diferencia entre un incidente contenido y una caída masiva que se lleva puesta la operación de la empresa.
Diseñar para resiliencia significa asumir el fallo como parte del sistema, no como una anomalía a evitar a toda costa.
Alta disponibilidad: eliminar puntos únicos de falla
La alta disponibilidad empieza por identificar cada componente que, si cae, tira todo el sistema con él: un balanceador sin réplica, una base de datos sin standby, un servicio de autenticación centralizado sin failover. La estrategia base:
- Redundancia activa-activa en las capas críticas (aplicación, cache, base de datos), no activa-pasiva donde el nodo de respaldo nunca se probó bajo carga real.
- Health checks agresivos que saquen instancias degradadas del pool antes de que generen errores en cascada.
- Balanceo de carga con criterio, no solo round-robin: latencia, salud del nodo y capacidad disponible.
Un sistema de alta disponibilidad bien construido no evita el fallo individual; evita que ese fallo se propague.
Redundancia geográfica: distribuir el riesgo, no solo la carga
Tener réplicas en una sola región resuelve fallos de instancia, pero no fallos de región. La redundancia geográfica implica:
- Multi-región activa-activa o activa-pasiva con failover automatizado, según el costo tolerable de latencia adicional.
- Replicación de datos con estrategia explícita de consistencia: si el negocio tolera eventual consistency, ganás disponibilidad; si necesita consistencia fuerte, el diseño se complica y hay que decidir conscientemente ese trade-off, no heredarlo por default.
- DNS con failover geográfico y pruebas periódicas de que el failover realmente redirige tráfico en el tiempo esperado, no solo en el papel.
La redundancia geográfica sin pruebas de failover regulares es, en la práctica, redundancia de mentira: existe en la infraestructura pero nadie sabe si funciona hasta que ya es tarde.
Tolerancia a fallos: contener el daño en el momento en que ocurre
Acá es donde se define si un fallo local se convierte en una caída masiva:
- Circuit breakers que corten llamadas a un servicio degradado en vez de dejar que las peticiones se acumulen y saturen todo lo que depende de él.
- Retries con backoff exponencial y jitter, nunca reintentos inmediatos en loop que amplifican la carga sobre un sistema ya comprometido.
- Bulkheads: aislar recursos (pools de conexión, threads, colas) por servicio para que la saturación de uno no consuma los recursos de los demás.
- Degradación controlada: definir de antemano qué funcionalidades se pueden apagar temporalmente para sostener el core del servicio.
Observabilidad y ejercicios de fallo controlado
Ninguna de estas capas sirve si no hay visibilidad para detectar el problema en segundos y no en horas. Métricas, trazas distribuidas y alertas accionables son la base. Y, como ejercicio hipotético: una empresa podría simular la caída de una región completa una vez por trimestre (chaos engineering básico) para validar que el failover automático funciona antes de necesitarlo en producción real.
Dónde entra la gobernanza
La resiliencia técnica sin gobernanza se degrada con el tiempo: nadie actualiza el runbook, el failover se prueba una vez y se olvida, las alertas se silencian porque generan ruido. Una auditoría periódica de arquitectura —revisar puntos únicos de falla, validar tiempos reales de recuperación, actualizar la documentación operativa— es lo que sostiene la resiliencia después del diseño inicial.
En Tinto & Bots trabajamos esa combinación: diseño de arquitectura resiliente y el proceso de gobernanza que garantiza que siga funcionando seis meses después de implementada.