Mantener la aplicación disponible cuando falla la caché

Introducción

La consulta de productos debe seguir funcionando si la caché opcional deja de responder. Observarás el fallo, configurarás una espera limitada y un acceso alternativo al origen, y recuperarás los aciertos al reanudar la caché.

Completa primero Add a Cache to a Product Lookup. Esta VM nueva incluye su propia aplicación, origen DynamoDB y nodo Valkey. Usa Terminal y AWS View. El control preparado pausa únicamente el proceso de caché de este laboratorio; no necesitas crear una herramienta de fallos.

Relación con la certificación

Observar un timeout real de caché

Un timeout limita cuánto espera la aplicación. Un proceso pausado conserva su endpoint pero no responde; esto es distinto de no encontrar una clave.

Confirma identidad y configuración:

cd /home/labex/project
aws sts \
  get-caller-identity
cat app.json

El ARN termina en labex-ca03-operator. Los ajustes iniciales son timeout_seconds: 2 y fallback_on_error: false. Consulta dos veces con la caché sana:

curl -sS http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101

La primera consulta lee el origen y la segunda usa la caché. Activa el fallo preparado:

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"pause"}' \
  http://127.0.0.1:8080/api/fault

Consulta incluyendo el estado HTTP:

curl -sS -w '\nHTTP %{http_code}\n' \
  http://127.0.0.1:8080/api/products/101

El fallo es intencionado: tras aproximadamente dos segundos, obtienes HTTP 503 y failure: TimeoutError, aunque DynamoDB conserva el producto. Una interrupción de caché no debería inutilizar automáticamente el catálogo.

Limitar la espera y recurrir al origen

El fallback es una ruta alternativa deliberada ante un error de caché. Un fallo de búsqueda normal solo significa que falta un valor.

Configura 0.2 segundos para esta demostración controlada y habilita el acceso alternativo:

jq '.timeout_seconds = 0.2 | .fallback_on_error = true' \
  app.json > app.next.json
mv app.next.json app.json

Mantén la caché pausada, consulta y muestra el tiempo transcurrido:

curl -sS -w '\nHTTP %{http_code}; elapsed %{time_total}s\n' \
  http://127.0.0.1:8080/api/products/101

Obtienes HTTP 200, el precio actual 20.00, served_from: source y cache_error: TimeoutError. La espera es de aproximadamente 0.2 segundos. Cada solicitud durante la interrupción añade una lectura de DynamoDB: conserva la función, pero aumenta la carga del origen.

En AWS View, compara el timeout, el estado pausado y las lecturas. Este ejercicio no determina un timeout de producción, capacidad de carga ni garantías de disponibilidad de AWS.

Recuperar la caché y sus aciertos

Reanudar los aciertos y responder desde el origen durante el fallo son resultados distintos. Retira el fallo controlado:

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"resume"}' \
  http://127.0.0.1:8080/api/fault

Consulta dos veces:

curl -sS http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101

Observa served_from: cache y cache_error: null. Si el TTL anterior caducó, la primera solicitud rellena la clave y la siguiente acierta. Las lecturas del origen dejan de aumentar durante aciertos consecutivos.

Deja la caché reanudada y el fallback limitado habilitado para verificar. En un servicio real, vigila errores y tráfico adicional al origen; el fallback no puede recuperar una base de datos también indisponible.

Resumen

Observaste un timeout real al pausar Valkey, habilitaste una ruta alternativa con espera limitada y recuperaste aciertos reales. La ausencia de una clave y un error requieren tratamientos distintos; el fallback conserva las respuestas del origen a costa de más trabajo de DynamoDB.

Para ampliar este tema, consulta la referencia de AWS: Elegir tiempos de espera del cliente según la carga.