APRENDER. PRATICAR. EVOLUIR.O estado HTTP pertence a um salto
Um pedido pode ter vários resultados compatíveis ao atravessar intermediários. No grupo /revalidate, a primeira leitura guarda validated-body com um ETag conhecido. Depois da expiração, o proxy contacta a origem com um validador, recebe 304 e entrega 200 com o corpo guardado ao cliente. A comparação útil alinha recurso, instante, estado da cache e validador. Não exige que todos os códigos sejam iguais. Num handover fictício, a equipa da origem e APS podem apresentar capturas corretas de saltos distintos. Pede a sequência completa antes de atribuir à rede a perda de um corpo que a resposta 304 não deveria transportar.
Separar validade HTTP de atualidade de negócio
Num exercício de cálculo, considera lifetime de 60 segundos e current_age já calculado de 45 segundos, sem outras restrições. Restam 15 segundos até deixar de ser fresh. Este cálculo não determina quando foi calculado um preço nem se já chegou o último ficheiro de posições. O laboratório não mede a idade dos dados de uma aplicação financeira. Para esse contexto, acrescenta versão, momento de produção e requisito da operação à evidência técnica. Uma resposta recém-validada pode refletir uma origem cujo processamento de negócio está atrasado. Não substituas a validação funcional por um valor de TTL ou pelo sucesso de uma troca condicional.
Observar a falha que a cache pode esconder
Os endpoints /stale e /strict começam com last-known-value e validade curta. Depois de expirar, a origem fictícia entra em modo de falha e devolve 503. O primeiro endpoint permite conteúdo expirado nesta condição; o segundo mantém a política estrita do ensaio. O cliente observa 200 STALE no primeiro e 503 no segundo. Consulta também upstream no log: o 200 não é prova de recuperação da origem. Esta comparação ensina a separar disponibilidade de uma representação anterior de disponibilidade de processamento atual. Não transforma servir conteúdo expirado numa escolha universal; é preciso definir quando a operação aceita esse compromisso.
Decidir por operação, com critérios de saída
Num caso fictício, um painel informativo aceita valores atrasados, mas uma decisão de liquidação exige valores atuais. Define duas linhas na grelha: consulta degradada permitida e decisão suspensa até existir evidência suficiente. Regista quem aceita a degradação, como o atraso é comunicado e que observação permite sair desse estado. Aumentar o número de respostas 200 não satisfaz automaticamente estes critérios. A equipa pode considerar uma fonte alternativa aprovada, mas precisa de validar equivalência e reconciliação. Esta aula não define normas internas de um banco; fornece um exercício de negociação entre suporte, aplicação e responsável funcional.
Praticar o handover em inglês
Reserva quinze minutos para escrever uma atualização curta em inglês com os resultados do laboratório. Usa a frase Cached reads remain available; origin recovery is not confirmed e acrescenta recurso afetado, versão observada, restrição funcional e próximo ponto de atualização. Um colega assume o papel de responsável de negócio e pergunta se pode retomar a operação. Responde com o critério de aceitação, sem usar STALE como palavra que o interlocutor tenha de interpretar sozinho. Depois identifica que informação é observada e que informação é hipótese. Este é um exercício proposto ao formando; não representa um workshop humano já realizado nesta revisão.
Fechar com uma prova de recuperação
A grelha final deve permitir que outra equipa repita o raciocínio: identifica a operação, o corpo esperado, a versão necessária, os estados por salto e o resultado de uma leitura autorizada. Se foi alterada a política de cache, inclui a validação após reversão e o tratamento de entradas anteriores. Uma leitura de diagnóstico com bypass não substitui o percurso normal. Termina com três conclusões separadas: o que já funciona, o que continua degradado e o que não foi ensaiado. No laboratório permanecem fora do âmbito TLS, caches de browser, autenticação, concorrência e dados reais. Mantém essas limitações quando apresentares o resultado a uma equipa de produção.
CACHE RECOVERY WORKSHEET / GRELHA DE RECUPERACAO
Operation / Operacao:
Expected resource and variant / Recurso e variante esperados:
Required business version and freshness / Versao e atualidade necessarias:
Client status, cache state, upstream status / Estados por salto:
Observed body version / Versao observada:
Permitted degraded use / Uso degradado permitido:
Blocked operation / Operacao bloqueada:
Owner and next update / Responsavel e proxima atualizacao:
Ordinary-path recovery evidence / Evidencia de retoma no percurso normal:
Rollback and previous entries / Reversao e entradas anteriores:
Remaining untested scope / Ambito ainda nao ensaiado:
O mesmo 503 na origem resulta em 200 STALE num endpoint e 503 noutro. A continuidade observada depende da política e do uso permitido dos dados.
Armadilhas comuns
Fechar o incidente pela taxa de 200, confundir TTL com idade do preço ou interpretar o corpo ausente num 304 como truncagem da resposta ao cliente.
Tópicos relacionados: O pedido e a representação pretendida · Cache, variantes e validação · Diagnóstico e orçamento de tempo
Recuperação exige evidência funcional e técnica compatível com a operação; servir uma representação antiga pode ser apenas continuidade degradada.
Referência: RFC 9111: HTTP Caching · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance