"Tenemos alta disponibilidad" es una de las frases más repetidas — y menos verificadas — en arquitectura de software. Tener dos servidores detrás de un balanceador no es alta disponibilidad. Es redundancia básica. Y la redundancia básica falla exactamente cuando más la necesitas: bajo carga real, con fallos correlacionados, en el peor momento posible.
La alta disponibilidad es una propiedad de diseño, no una configuración que se activa. Implica decisiones arquitectónicas que afectan cada capa del sistema, desde cómo manejas el estado hasta cómo defines qué significa "disponible" para tu negocio.
Los números: lo que realmente significa cada 9
Los SLA se expresan en porcentajes, pero los ingenieros deberían pensar en minutos de downtime. La diferencia entre cada "nueve" es un orden de magnitud en complejidad y costo:
- 99.9% (tres nueves): ~8.7 horas de downtime al año. Suficiente para la mayoría de aplicaciones internas. Alcanzable con redundancia básica y monitoreo.
- 99.99% (cuatro nueves): ~52 minutos al año. Requiere failover automatizado, health checks agresivos y eliminación de single points of failure. Aquí es donde la mayoría de los equipos subestiman la complejidad.
- 99.999% (cinco nueves): ~5 minutos al año. Requiere arquitectura active-active multi-región, zero-downtime deployments y una disciplina operacional que pocos equipos tienen. El costo se multiplica exponencialmente.
La pregunta correcta no es "¿cuántos nueves queremos?" sino "¿cuánto downtime puede tolerar el negocio y cuánto estamos dispuestos a invertir para reducirlo?"
Patrones de HA: Active-Passive, Active-Active, Multi-región
Active-Passive es el patrón más común y el más engañoso. Un nodo primario procesa todo el tráfico mientras un secundario espera en standby. Suena simple. El problema: el nodo pasivo no ha procesado tráfico real en semanas. Cuando el primario falla y el pasivo toma el control, descubres que tiene una versión diferente del schema, que el pool de conexiones no estaba caliente, o que un cronjob local no se configuró en el secundario. El failover que funcionaba en el runbook no funciona en la realidad.
Active-Active elimina ese problema: ambos nodos procesan tráfico simultáneamente. Si uno cae, el otro absorbe la carga completa. Pero introduce otro problema: consistencia de datos. Si ambos nodos pueden escribir, necesitas resolver conflictos. Esto implica decisiones sobre replicación síncrona vs. asíncrona, eventual consistency, y CRDT o conflict resolution strategies.
Multi-región lleva active-active al nivel geográfico. El tráfico se distribuye entre regiones y si una región completa cae, las demás absorben la carga. Aquí la latencia entre regiones se convierte en el factor dominante. La replicación síncrona entre continentes es prohibitiva en la mayoría de los casos.
Los componentes invisibles: lo que realmente sostiene la HA
Los diagramas de arquitectura muestran servidores y flechas. Lo que no muestran es lo que hace funcionar el sistema:
- Health checks: No basta con verificar que el proceso responde. Un health check real valida conectividad a la base de datos, acceso a servicios críticos, espacio en disco y capacidad de procesamiento. Un health check superficial es peor que no tenerlo — te da una falsa sensación de que el nodo está sano.
- Heartbeats: El mecanismo por el cual los nodos de un cluster confirman que están vivos. La frecuencia del heartbeat define qué tan rápido detectas un fallo. Muy frecuente y saturas la red. Muy espaciado y tardas demasiado en reaccionar.
- Quorum: En un cluster de N nodos, ¿cuántos necesitan estar de acuerdo para tomar una decisión? El quorum previene el split-brain, pero requiere un número impar de nodos y tolerancia a particiones de red.
- Split-brain: El escenario más peligroso en HA. Dos nodos pierden comunicación entre sí y ambos asumen que son el primario. Resultado: dos fuentes de verdad, datos inconsistentes, corrupción. Resolverlo requiere fencing (STONITH), quorum disks o un tercer nodo árbitro.
Decisiones de diseño: dónde poner el estado
La mayor enemiga de la alta disponibilidad es el estado. Los servicios stateless escalan y se recuperan fácilmente. Los stateful son los que complican todo.
- Sesiones: No las guardes en memoria del servidor. Usa un store externo (Redis, base de datos) o tokens stateless (JWT). Si un nodo cae, las sesiones no deberían perderse.
- Caché: Decide si la caché es prescindible o crítica. Si es prescindible, un cache miss es aceptable tras un failover. Si es crítica, necesitas replicación.
- Base de datos: La decisión más costosa. Replicación síncrona garantiza consistencia pero añade latencia. Replicación asíncrona es más rápida pero acepta pérdida de datos en failover. No hay opción correcta universal — hay trade-offs que debes entender.
Y algo que se olvida frecuentemente: no todo necesita ser replicado. Logs locales, caches temporales, datos derivados que pueden recalcularse — replicar todo multiplica la complejidad sin beneficio proporcional.
El anti-patrón: "PowerPoint HA"
Existe un tipo de alta disponibilidad que solo funciona en presentaciones. El diagrama muestra dos data centers, flechas de replicación y un load balancer global. Pero nadie ha probado el failover. Nadie sabe cuánto tarda. Nadie ha validado que los datos se replican correctamente bajo carga.
He visto arquitecturas "multi-region active-active" donde el failover manual tardaba 45 minutos porque requería cambiar DNS, actualizar configuraciones, reiniciar servicios en orden específico, y verificar la integridad de los datos manualmente. Eso no es HA. Es un plan de recuperación lento disfrazado de arquitectura resiliente.
La única forma de saber si tu HA funciona es probarla. Chaos engineering, failover drills, game days. Si nunca has matado un nodo primario en producción deliberadamente, no sabes si tu sistema sobrevive a un fallo real.
Lo que nadie te dice sobre el costo
Cada nueve adicional multiplica el costo. No solo en infraestructura — en complejidad operacional, en horas de ingeniería, en herramientas de monitoreo, en procesos de on-call. Un sistema con 99.999% de disponibilidad requiere un equipo que viva y respire operaciones. No es solo un diseño. Es una cultura.
La conversación honesta con el negocio es: "¿Cuánto dinero perdemos por hora de downtime? ¿Cuánto cuesta diseñar y operar un sistema que reduzca ese downtime?" Si el costo de HA supera el costo del downtime, estás sobrediseñando.
Un sistema no es de alta disponibilidad hasta que ha sobrevivido a un fallo real. Los diagramas no fallan. Los sistemas sí. Diseña para el fallo, no para la presentación.
