Manter a aplicação funcionando quando o cache falha

Introdução

A consulta deve continuar utilizável quando o cache opcional não responde. Observe a falha, limite a espera e habilite uma alternativa à origem; depois retome o cache e os hits.

Conclua Add a Cache to a Product Lookup. Esta VM independente fornece aplicação, DynamoDB e Valkey próprios. Use Terminal e AWS View. O controle preparado pausa somente o processo de cache deste laboratório; não é necessário construir uma ferramenta de falhas.

Relação com a certificação

Observar um timeout real

Um timeout limita quanto a aplicação espera. Um processo pausado conserva seu endpoint sem responder, diferentemente de uma chave ausente.

Confirme identidade e configurações:

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

O ARN termina em labex-ca03-operator. Os ajustes iniciais são timeout_seconds: 2 e fallback_on_error: false. Solicite duas vezes com o cache saudável:

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

A primeira consulta usa a origem; a segunda, o cache. Ative a falha preparada:

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

Solicite o produto incluindo o status HTTP:

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

A falha é intencional. Após cerca de dois segundos, a aplicação retorna HTTP 503 e failure: TimeoutError, embora o banco ainda contenha o produto. Uma falha de cache não deve automaticamente interromper o catálogo.

Limitar a espera e recorrer à origem

Fallback é um caminho alternativo deliberado após um erro do cache. Um miss comum indica apenas uma cópia ausente.

Nesta demonstração controlada, configure 0.2 segundo e habilite fallback:

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

Mantenha o cache pausado e mostre o tempo da solicitação:

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

HTTP 200 retorna preço atual 20.00, served_from: source e cache_error: TimeoutError. A espera controlada agora é cerca de 0.2 segundo. Cada solicitação durante a falha acrescenta uma leitura DynamoDB: mantém a funcionalidade, mas aumenta a carga da origem.

Em AWS View, compare timeout, estado pausado e contador. Essa medição em um ambiente não define timeout de produção, capacidade de carga ou garantias de disponibilidade AWS.

Restaurar o cache e observar acertos

Cache saudável e fallback bem-sucedido são resultados diferentes. Retome o processo:

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

Solicite o produto duas vezes:

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

Observe served_from: cache e cache_error: null. Se o TTL inicial expirou, a primeira solicitação repovoa a chave da origem e a seguinte é um hit. O contador deixa de crescer durante hits consecutivos.

Deixe o cache retomado e o fallback limitado habilitado para verificar. Em um serviço real, monitore erros e tráfego adicional; fallback não torna disponível um banco que também falhou.

Resumo

Você observou um timeout real com o cache pausado, habilitou fallback limitado e restaurou hits. Misses e erros precisam de tratamentos distintos; fallback conserva respostas à custa de trabalho adicional no banco.

Para aprofundar o tema, consulte a documentação da AWS: Escolher tempos limite do cliente conforme a carga.