Marco del problema de tolerancia a fallos

Para los usuarios, la tolerancia a fallos se manifiesta como una inconsistencia en el comportamiento, no como una situación binaria clara de funcionamiento o caída total. Una interrupción parcial puede seguir devolviendo respuestas 200 mientras las funcionalidades se degradan silenciosamente, o bien mantener operativas las funciones principales mientras todo se percibe lento debido a la acumulación de solicitudes en una dependencia.

La fiabilidad percibida depende principalmente de la duración de la mala experiencia. Cuando la recuperación lleva minutos en lugar de segundos, los usuarios reintentan la acción, los clientes amplifican la carga, las cachés se renuevan constantemente y las colas se saturan; a menudo, el sistema resulta más difícil de recuperar incluso después de que el fallo original ha cesado.

Para visualizar mejor estas consecuencias perceptibles para el usuario, interactúe con los escenarios que se presentan a continuación y observe cómo los distintos síntomas influyen en la disposición del usuario a seguir intentándolo.

Un mismo fallo subyacente puede generar experiencias muy distintas según qué componente falle y cómo reaccione el sistema. Los picos de errores son evidentes, pero los tiempos de espera agotados (timeouts) suelen percibirse peor, ya que bloquean los flujos de trabajo del usuario mientras consumen capacidad del servidor; asimismo, las lecturas de datos obsoletos pueden ser aceptables o catastróficas dependiendo de la funcionalidad.

Un sistema mínimo y sus límites de fallo

La mayoría de los debates sobre tolerancia a fallos ganan claridad cuando se localizan los fallos en un conjunto reducido de componentes y en los límites que los separan. En una configuración de producción mínima, un cliente invoca un servicio sin estado, dicho servicio lee y escribe en un almacén de datos, y el rendimiento depende de si la ruta de la solicitud encuentra información en caché o debe esperar a una dependencia más lenta.

Utilice el esquema representado para identificar dónde pueden detenerse las solicitudes, dónde puede perderse el estado y dónde debería aplicarse contrapresión (backpressure) para frenar la carga antes de que esta se propague.