El servidor como punto único

La latencia y la disponibilidad parecen problemas separados, pero son el mismo problema medido en dos escalas. Una respuesta que tarda mucho y una respuesta que no llega difieren en grado, no en naturaleza: en ambos casos el usuario está esperando algo que depende de una máquina que no controla. Cuando esa dependencia está en el camino crítico de cada interacción, has convertido una decisión de arquitectura en un punto único de fallo.

Cuatro maneras de no estar

Cuando decimos que el servidor “no está”, solemos pensar en un servidor caído. Es el caso menos frecuente y el mejor tratado. Hay otros tres, y son más interesantes.

El servidor caído no responde en absoluto. Es un fallo limpio: se detecta pronto, se distingue con claridad y activa los mecanismos previstos. El servidor lejano responde perfectamente, pero desde el otro lado del planeta; cada interacción hereda el suelo geográfico del nivel anterior y la aplicación se siente pastosa sin que ningún panel muestre un solo error. El servidor saturado responde a veces, tarde y de forma irregular; es el peor de los cuatro. Y el cuarto no es un fallo del servidor en absoluto: eres tú quien no está, en un tren que atraviesa un túnel, en un avión, en un sótano, en un país con itinerancia cara o en una red que bloquea lo que necesitas.

flowchart LR
A[Servidor caido] --> Z[La aplicacion no responde]
B[Servidor lejano] --> Z
C[Servidor saturado] --> Z
D[Usuario sin conexion] --> Z
Z --> W[Para la persona son el mismo suceso]
style Z fill:#f38ba8,color:#11111b
style W fill:#f9e2af,color:#11111b

Los cuatro tienen causas distintas, dueños distintos y remedios distintos. Para la persona sentada delante son indistinguibles: la aplicación no hace lo que le pide. Esa indistinguibilidad es el dato central del capítulo, porque significa que mejorar tres de los cuatro deja el problema intacto.

La consecuencia práctica de esa ambigüedad es que la entrega exactamente una vez no es alcanzable sobre una red no fiable: solo se puede elegir entre entregar como mucho una vez, arriesgando perder la operación, o al menos una vez, arriesgando repetirla. La salida no consiste en resolver la ambigüedad, que es irresoluble, sino en volverla inofensiva haciendo que repetir no cause daño.

// La clave no evita el reenvio: hace que el reenvio sea inocuo
const operacion = {
  clave: identificadorUnicoDeIntento,  // estable entre reintentos
  tipo: 'transferir',
  datos,
};

// El receptor recuerda las claves ya aplicadas y descarta duplicados

La disponibilidad se compone, y se compone mal

Es tentador leer la disponibilidad como una cifra que el proveedor publica. Esa cifra describe un centro de datos; lo que el usuario experimenta es otra cosa.

La disponibilidad extremo a extremo de una interacción es, aproximadamente, el producto de la disponibilidad de todos los elementos que están en serie en su camino crítico: su dispositivo, su enlace, la red intermedia, el balanceador, el servicio, la base de datos y cualquier dependencia que el servicio consulte antes de responder. Multiplicar números menores que uno solo puede dar un número menor. Cada dependencia añadida al camino crítico reduce la disponibilidad, nunca la aumenta, salvo que se añada en paralelo con conmutación real.

// En serie, la disponibilidad se multiplica: cada eslabon resta
const enSerie = eslabones.reduce((acc, e) => acc * e.disponibilidad, 1);

// El eslabon que casi nadie instrumenta es el primero
const enlaceDelUsuario = 'tren, tunel, avion, itinerancia, wifi de hotel';

Y aquí está la asimetría incómoda: el eslabón menos fiable de la cadena suele ser el primero, el enlace del propio usuario, y es justamente el único que ni tú ni tu proveedor podéis mejorar. Todo el esfuerzo de redundancia se concentra donde ya es muy fiable, y el eslabón débil queda fuera del alcance de la ingeniería y también fuera del alcance de la medición, porque cuando ese eslabón falla no llega ningún dato al panel que registraría el fallo.

La redundancia funciona, pero solo en la posición correcta. Poner dos elementos en paralelo con conmutación automática eleva la disponibilidad de ese punto, porque hace falta que fallen los dos a la vez. Poner dos elementos en serie la baja, porque basta que falle uno. Buena parte de las arquitecturas que se describen a sí mismas como redundantes tienen, en realidad, mucha redundancia en el interior y una larga cadena en serie desde el usuario hasta ese interior; y la disponibilidad extremo a extremo la fija la cadena, no el interior.

Las tres degradaciones

Ante la pérdida de conexión, una aplicación puede estar diseñada de tres maneras, y la diferencia entre ellas no es de esfuerzo sino de dónde vive la autoridad sobre el dato.

El salto interesante es el segundo, del solo lectura al local completo. Leer de una caché es fácil porque no crea información nueva: como mucho muestras algo viejo. Aceptar una escritura sin coordinación crea información que nadie más conoce todavía, y por tanto abre la posibilidad de que dos dispositivos creen información incompatible. Toda la maquinaria de relojes lógicos, detección de conflictos y convergencia que ocupa los niveles siguientes de este recorrido existe para pagar exactamente esa factura.

La red como mejora, no como requisito

Las tres degradaciones se pueden resumir en una sola pregunta de diseño: ¿la conexión es un requisito de la interacción o una mejora de la interacción?

Si es un requisito, la disponibilidad de la aplicación está acotada por arriba por la disponibilidad del enlace más débil, que no controlas. Si es una mejora —la interacción se completa localmente y la red sirve para propagar, respaldar y compartir— entonces la disponibilidad está acotada por si el dispositivo enciende, que es un umbral radicalmente distinto.

// Requisito: sin red no hay lectura, y el usuario espera
async function tareasComoRequisito() {
  return await pedirAlServidor('/tareas');
}

// Mejora: la lectura es local y la red solo mantiene fresca la replica
function tareasComoMejora() {
  sincronizarEnSegundoPlano();   // si hay red; si no, mas tarde
  return leerDeLaReplicaLocal(); // devuelve ya, haya red o no
}

Las dos funciones resuelven la misma necesidad de producto y describen aplicaciones incomparables. La segunda no es simplemente más rápida: su tiempo de respuesta y su disponibilidad han dejado de depender de una variable externa.

Este reencuadre tiene una virtud práctica que va más allá de la resiliencia. Cuando la red es un requisito, cada nueva funcionalidad hereda automáticamente la fragilidad del enlace y el equipo acaba escribiendo, una y otra vez, el mismo tratamiento de errores de conectividad en sitios distintos. Cuando la red es una mejora, ese tratamiento se concentra en un solo lugar —el motor que propaga— y el resto del producto se escribe contra un almacén local que siempre responde. La diferencia de complejidad acumulada, a lo largo de años, es considerable, y va en la dirección contraria a la que la intuición sugiere.