Fallback
Qué es
Fallback define una respuesta o estrategia alternativa cuando la operación primaria no puede completarse bajo las condiciones previstas. Puede usar datos cacheados, una respuesta menos personalizada, otro proveedor o una funcionalidad reducida. El resultado debe conservar un significado explícito para el consumidor.
El patrón no obliga a devolver datos. Si ninguna alternativa satisface el mínimo de corrección, la salida adecuada es comunicar indisponibilidad claramente. Presentar un valor inventado como resultado verdadero altera el contrato, aunque el transporte responda con éxito.
Polly describe una estrategia que sustituye resultados ante fallos seleccionados y permite observar su activación. Esa implementación ilustra la separación entre detectar el fallo y decidir la alternativa; no define por sí sola qué respuesta es válida para el dominio.
Qué problema resuelve
Una página necesita recomendaciones personalizadas y el servicio encargado no responde. Mostrar una selección genérica puede mantener útil la página, a costa de personalización. La intención mínima sigue siendo ofrecer productos relevantes, sin prometer que se usaron preferencias individuales.
En cambio, si una consulta de saldo no puede acceder a datos confiables, devolver cero como supuesto saldo puede provocar decisiones equivocadas. Un último saldo conocido, si el producto permite mostrarlo, necesita fecha y alcance explícitos; no debe presentarse como saldo actual ni habilitar decisiones que requieren otro nivel de certeza.
Estos ejemplos son decisiones de diseño, no reglas automáticas por industria. La pregunta es qué propiedades del resultado pueden degradarse sin corromper su significado y qué expectativas mantiene el usuario.
Formas de degradación
| Alternativa | Qué conserva | Qué necesita explicitar |
|---|---|---|
| Datos en caché | Una observación previamente obtenida | Frescura, origen y condiciones de validez. |
| Datos stale | Un resultado anterior aunque ya venció su frescura normal | Antigüedad máxima tolerada y restricciones de uso. |
| Defaults | Un valor previsto por el contrato | Que es un default, no una observación confirmada. |
| Otro proveedor | Una operación mediante otro camino | Equivalencia semántica, capacidad y efectos posibles. |
| Funcionalidad reducida | Parte de la experiencia | Qué falta y qué operaciones siguen permitidas. |
| Indisponibilidad explícita | La honestidad del resultado | Qué no pudo confirmarse y cómo continuar. |
Caché no implica que el dato sea stale: puede estar dentro de su ventana de frescura. Tampoco toda respuesta cacheada es un fallback; puede ser el camino normal. Se convierte en alternativa cuando reemplaza deliberadamente al resultado primario bajo una condición definida.
Google SRE describe respuestas degradadas que cuestan menos de calcular, incluyendo resultados menos completos o copias locales. También señala que una sobrecarga extrema puede impedir incluso servir esas respuestas. Graceful degradation conserva utilidad dentro de límites; no garantiza disponibilidad ilimitada.
Contrato de activación y resultado
La política debe identificar qué condiciones habilitan el fallback. Un error transitorio, un timeout o un rechazo de circuit-breaker pueden justificar evaluarlo. Un error de autorización no debería transformarse en una respuesta exitosa que el usuario no tiene permiso para recibir.
También hay que definir la mínima calidad aceptable, la vigencia de los datos, cuánto tiempo puede durar la degradación y cómo se recupera el camino normal. «Usar caché si falla» deja abiertas preguntas importantes: qué sucede si está vacía, si pertenece a otro tenant o si una revocación volvió inválido el acceso.
La preferencia por disponibilidad no permite afirmar hechos que no se conocen. Una respuesta parcial debe distinguir campos ausentes de valores cero; una recomendación genérica no debe fingir personalización. Cuando el contrato exige certeza actual, fallar claramente es más correcto que ocultar incertidumbre.
Ejemplo: recomendaciones durante una caída
El servicio de recomendaciones dispone de una lista genérica preparada y actualizada por un proceso independiente. Si no llega una respuesta personalizada dentro del tiempo disponible, la página puede usar esa lista, marcada como selección general.
La alternativa no consulta nuevamente el mismo servicio caído. Si la lista tampoco está disponible o ya no satisface sus condiciones de vigencia, se omite el bloque de recomendaciones y se conserva la navegación del catálogo. La omisión es otra salida expresamente admitida, no una cascada abierta de intentos improvisados.
El diseño debe comprobar categorías permitidas, disponibilidad comercial y reglas de acceso en los datos alternativos. Que la lista haya sido válida ayer no demuestra que siga siendo adecuada. La política de actualización y sus responsables son parte del costo del fallback.
Capacidad y fallas de la alternativa
El fallback también usa CPU, memoria, conexiones o servicios externos y puede fallar. Una alternativa atendida esporádicamente quizá no soporte el tráfico completo que recibe al caer el primario. Compartir su cuello de botella puede hacer que falle exactamente cuando más se necesita.
AWS relata un incidente donde el fallback de una caché enviaba consultas directamente a la base de datos; al fallar las cachés juntas, esa carga bloqueó la base y propagó el impacto. La lección es comprobar la capacidad y los fallos conjuntos, no asumir que otra ruta siempre mejora disponibilidad. Avoiding fallback in distributed systems.
Limitar la alternativa con bulkhead, tiempo y presupuesto de carga puede contener el daño. No conviene formar una cadena sin límite donde cada fallo dispara otro proveedor, otro retry o más trabajo caro. Reservar tiempo dentro de deadline importa: agotar todo el presupuesto en el primario deja sin margen al fallback.
Diferencias con otros patrones
Fallback no equivale a retry. Retry repite la misma intención bajo una política; Fallback cambia el mecanismo o el resultado admitido. Enviar otra tentativa a una réplica equivalente puede ser un retry con failover, sin implicar degradación semántica. Usar una aproximación o reducir funcionalidad sí cambia las condiciones del resultado.
Fallback no equivale a Circuit Breaker. El breaker puede rechazar llamadas al primario y disparar la evaluación de una alternativa, pero no decide qué datos sustitutos son correctos. Un fallback puede activarse sin breaker y un breaker puede terminar en indisponibilidad explícita, sin respuesta sustituta.
Cambiar de proveedor tampoco elimina efectos inciertos. Si un cobro pudo ejecutarse antes del Timeout, cobrar con otro proveedor puede duplicarlo. idempotency necesita cubrir la intención y el alcance real de ambas rutas; no basta con que cada proveedor deduplique sus propias solicitudes.
Observabilidad y cuándo usarlo
Registrar la causa primaria, activaciones, alternativa elegida, frescura, fallos del fallback y resultado para el usuario. Medir únicamente respuestas exitosas puede ocultar un incidente prolongado detrás de resultados degradados. Diferenciar éxito completo, degradación aceptada e indisponibilidad mantiene visible la salud real.
Ejercitar la alternativa bajo carga y revisar sus supuestos cuando cambian datos, permisos o comportamiento del producto. Un camino rara vez usado puede quedar obsoleto aunque el primario esté saludable.
Usarlo cuando exista una alternativa semánticamente válida y operativamente sostenible. Evitarlo cuando encubra hechos desconocidos, traslade una sobrecarga o dependa de supuestos que nadie mantiene. resilience-patterns conecta esa elección con espera, repetición y aislamiento.