¿Cuáles son los modos de fallo comunes en sistemas distribuidos — particiones de red, split-brain, desfase de reloj — y cómo defenderse de ellos?

#Los sistemas distribuidos fallan de formas que una sola máquina no conoce

Un proceso único o funciona o no funciona; rara vez hay que razonar sobre que esté "medio vivo". Un sistema distribuido introduce toda una nueva superficie de fallo porque la red en sí es poco fiable, y porque no existe un reloj compartido — dos máquinas pueden comportarse perfectamente bien de forma aislada y aun así producir juntas un resultado gravemente incorrecto. Los modos de fallo que hay que dominar para una entrevista senior son las particiones de red, el split-brain (una consecuencia específica y peligrosa de una partición) y el desfase de reloj, junto con las defensas que convierten cada uno en algo sobrevivible en lugar de catastrófico.

#Particiones de red

Una partición es cualquier situación en la que un subconjunto de nodos no puede comunicarse con otro subconjunto, aunque cada nodo individual esté por lo demás sano. Esto no es exótico — ocurre por un switch de rack defectuoso, un grupo de seguridad mal configurado, un enlace entre regiones saturado, o un despliegue rutinario que corta conexiones brevemente. Lo peligroso no es la partición en sí; es que cada lado de la partición normalmente no puede distinguir entre "el otro nodo está caído" y "el otro nodo está bien pero inalcanzable desde aquí" — y la respuesta correcta a esas dos situaciones es completamente distinta (hacer failover es correcto en el primer caso, y activamente dañino en el segundo).

#Split-brain: dos líderes, una sola verdad

El split-brain ocurre cuando una partición hace que dos subconjuntos disjuntos de un clúster concluyan cada uno, de forma independiente, que deberían tener un líder, resultando en dos nodos que creen simultáneamente ser el líder y aceptan escrituras. Ambos lados siguen operando "correctamente" desde su propio punto de vista — eso es lo que lo hace tan peligroso, porque no hay ningún error que detectar localmente. El daño se descubre después, cuando la partición se cura y te encuentras con dos historiales divergentes de escrituras que ambos se declaran autoritativos y que no se pueden simplemente concatenar.

En el diagrama, el Nodo 1 queda aislado pero sigue aceptando escrituras del Cliente X porque nada localmente le indica que debe detenerse — no puede contactar a los demás nodos para enterarse de que perdió la votación. Mientras tanto, los Nodos 2 y 3 siguen formando una mayoría, eligen correctamente un nuevo líder, y empiezan a aceptar escrituras del Cliente Y. Ahora existen dos historiales aparentemente autoritativos para los mismos datos, y reconciliarlos cuando la red se recupere puede requerir descartar por completo las escrituras de uno de los dos lados.

#Defenderse del split-brain: quorums y fencing

La defensa estándar es el quorum mayoritario: un nodo solo puede actuar como líder si puede confirmar que está en contacto con una mayoría estricta del clúster (⌊n/2⌋ + 1). Con un número impar de nodos, una partición puede producir a lo sumo un lado con mayoría — así que en el ejemplo de 3 nodos, el lado minoritario (1 nodo) matemáticamente no puede también reclamar mayoría, y un nodo correctamente implementado debería renunciar en lugar de seguir sirviendo escrituras en cuanto detecta que perdió el quorum. Esto es exactamente lo que formalizan los protocolos de consenso como Raft y Paxos: el liderazgo es un lease respaldado por acuerdo mayoritario, no un título permanente.

Una segunda defensa, complementaria, son los fencing tokens: cada vez que cambia el liderazgo, el nuevo líder recibe un token monótonamente creciente, y cualquier recurso downstream (un sistema de almacenamiento compartido, una base de datos) está obligado a rechazar escrituras que lleven un token más antiguo que el más alto que ya ha visto — incluso si el líder anterior sigue vivo y sigue convencido de estar al mando, sus escrituras se rechazan físicamente en el punto donde realmente surtirían efecto. Esto cierra el hueco que el quorum por sí solo no cubre: el quorum evita que un nodo minoritario crea que es un líder válido, pero un nodo puede tardar en notarlo (una pausa de GC justo después de perder una elección, por ejemplo), y los fencing tokens capturan ese caso residual en la capa de almacenamiento.

#Desfase de reloj: cuando "después" te miente

El reloj de cada máquina se desvía del tiempo real, la sincronización NTP es solo aproximadamente precisa (y puede saltar hacia atrás cuando corrige), y los entornos virtualizados/en contenedores pueden añadir sus propias anomalías de temporización. Esto importa enormemente cada vez que la corrección depende de comparar timestamps de máquinas distintas — por ejemplo, una estrategia de resolución de conflictos last-write-wins que elige "la escritura con el timestamp más reciente" puede en silencio elegir la escritura más antigua en términos de reloj real si la máquina que produjo el timestamp "más reciente" en realidad tiene un reloj adelantado.

Las defensas estándar no intentan que los relojes sean perfectos; rodean la necesidad de que lo sean. Los relojes lógicos (timestamps de Lamport) asignan un orden basado en causalidad — "este evento ocurrió después de aquel porque un mensaje que llevaba su timestamp llegó primero" — en lugar de tiempo de reloj real, dando un orden parcial correcto sin ninguna sincronización de relojes. Los vector clocks extienden esto para detectar eventos concurrentes (no solo ordenados), que es lo que permite a un sistema como Dynamo decir "estas dos escrituras genuinamente ocurrieron en concurrencia, que la aplicación las fusione" en lugar de adivinar. En el extremo más avanzado, Spanner de Google usa TrueTime, una API que devuelve no un único timestamp sino un intervalo de confianza [earliest, latest] respaldado por relojes atómicos y receptores GPS en cada centro de datos, y simplemente espera a que pase la ventana de incertidumbre antes de confirmar una transacción — convirtiendo "los relojes son imprecisos" en una cantidad acotada y conocida en lugar de desconocida.