Failover es un proceso automático que detecta la falla de un componente primario (servidor, base de datos, servicio) y redirige el tráfico o las operaciones a un componente secundario o de respaldo que está listo para asumir la carga. Su objetivo principal es garantizar la continuidad del servicio y la alta disponibilidad, reduciendo el tiempo de inactividad percibido por los usuarios. Este mecanismo se basa en la redundancia, donde existen múltiples instancias de un componente, y en la monitorización constante para detectar fallos de manera proactiva.
En el mundo real, Failover es fundamental en sistemas distribuidos de misión crítica. Ejemplos concretos incluyen: bases de datos como PostgreSQL con Patroni o AWS RDS Multi-AZ, donde una instancia en espera toma el relevo automáticamente si la primaria falla. Sistemas de orquestación de contenedores como Kubernetes utilizan Failover para pods y nodos, moviendo cargas de trabajo a recursos disponibles. Balanceadores de carga como NGINX o HAProxy pueden configurar Failover para servidores backend. También es común en sistemas de almacenamiento (ej. RAID, SANs con controladoras redundantes) y en infraestructuras de red (ej. VRRP, HSRP para routers).
Para un arquitecto, el Failover es una consideración de diseño crítica para la resiliencia del sistema. Implica trade-offs significativos: la complejidad de la implementación aumenta con la necesidad de redundancia y mecanismos de detección de fallos. El costo se eleva debido a la duplicación de recursos. Es vital considerar el Recovery Time Objective (RTO) y el Recovery Point Objective (RPO): un Failover bien diseñado busca un RTO bajo (tiempo mínimo para restaurar el servicio) y un RPO bajo (mínima pérdida de datos). Las decisiones de diseño incluyen la elección entre Failover activo-pasivo o activo-activo, la granularidad del Failover (a nivel de componente, servicio o centro de datos) y la estrategia de Failback (cómo y cuándo el sistema regresa al componente primario una vez reparado).