APRENDER. PRATICAR. EVOLUIR.Começar pelo percurso e pela medida
Num portal fictício de reporting de fundos, a média de latência melhora depois de introduzir cache, mas os relatórios menos consultados continuam lentos. Antes de aumentar recursos, separa operações, tamanhos, clientes e períodos. Relaciona latência vista pelo utilizador, percentis, erros, throughput e espera nos componentes. Uma média rápida pode esconder uma cauda lenta; p95 não é a média dos 95% mais rápidos. Mantém o período e a população comparáveis entre versões. Dados agregados apenas como soma e contagem normalmente não permitem reconstruir percentis; preserva amostras ou histogramas adequados ao mecanismo de medição. Usa tracing e métricas de dependências para localizar espera, evitando atribuir à camada web um atraso causado pela base de dados.
Definir a identidade de uma representação
A chave de cache determina que pedidos podem partilhar uma resposta. No CloudFront, uma cache policy escolhe headers, cookies e query strings incluídos nessa chave; esses valores também seguem para a origem. Uma origin request policy pode encaminhar metadata adicional sem a acrescentar à chave. Isto é útil para telemetria, mas perigoso se o valor alterar o conteúdo, idioma ou âmbito autorizado: encaminhar um identificador de cliente não isola por si as respostas em cache. Primeiro prova equivalência semântica; depois remove dimensões desnecessárias de alta cardinalidade. Para conteúdo personalizado, uma solução pode ser desativar a cache nesse percurso. Não confundas chave de cache com autorização: separar variantes também não substitui verificar acesso a cada recurso.
Controlar validade e publicação de ficheiros
O TTL é uma política de validade, não uma garantia de residência até ao último segundo. O CloudFront pode remover objetos pouco usados antes da expiração. Minimum TTL superior a zero pode manter conteúdo apesar de no-store ou private; para um percurso que não pode ser guardado, confirma a política efetiva e não apenas headers da origem. Distingue max-age para clientes de s-maxage para caches partilhadas, respeitando os limites da cache policy. Conteúdo stale pode ser adequado a um documento informativo, mas não a um valor financeiro cuja frescura é obrigatória. Invalidar no CloudFront não esvazia automaticamente caches de browsers ou proxies empresariais. Ficheiros com nomes versionados ajudam a publicar e recuar, desde que o manifesto aponte para a revisão correta e os ficheiros antigos necessários sejam mantidos.
Conhecer o âmbito de cada mecanismo
Os cache behaviors são avaliados por ordem de correspondência, não por uma escolha automática da regra que parece mais específica. Revê os percursos públicos e privados em conjunto. Encaminhar POST não significa que a resposta será guardada, nem que o origin failover repetirá esse POST noutra origem. Desenha a continuidade das escritas ao nível adequado e preserva as decisões sobre repetição e efeitos de negócio. Origin Shield acrescenta uma camada que pode reduzir pedidos redundantes à origem, mas não corrige uma chave mal definida nem cria capacidade ilimitada. Mede o resultado com carga representativa. Um hit ratio elevado só demonstra reaproveitamento; não demonstra que a resposta pertence ao cliente certo ou cumpre o requisito de frescura.
Preparar miss, atualização e cache vazia
Em lazy loading, um miss leva a aplicação ao armazenamento autoritativo e depois preenche a cache. A cópia pode ficar desatualizada se uma escrita alterar apenas a base de dados. Write-through acrescenta atualização da cache ao percurso de escrita, mas exige tratar falhas parciais e não preenche automaticamente um nó novo com todos os registos históricos. Combinar mecanismos exige um contrato explícito, não a promessa genérica de consistência forte. TTL limita a vida de uma cópia, sem garantir que nunca fica stale. Ensaiar cache vazia permite medir a pressão sobre a origem; uma limpeza global pode aumentar bruscamente a carga. Planeia limites de concorrência e recuperação gradual, mantendo critérios de correção e prazo para operações críticas.
Demonstrar melhoria com um modelo delimitado
No exercício original, chegam 2000 leituras por segundo e cada miss produz exatamente uma consulta à origem. Com 95% de hits, são 100 consultas por segundo; com 80%, são 400. O modelo não inclui coalescência, retries, escritas, revalidação nem limites AWS. Serve para tornar visível uma dependência que uma média esconde. O ensaio real deve incluir o mix de operações, datasets relevantes, caches quentes e frias e condições de pico, usando dados sintéticos ou saneados. Mantém uma referência anterior e compara com limites definidos antes do teste. O PM reúne aplicação, APS e owners de dados para aceitar a melhoria com evidência de correção, capacidade degradada e observabilidade, além da latência.
read_rate = 2000
hit_ratios = [0.95, 0.80]
origin_queries = [round(read_rate * (1 - hit)) for hit in hit_ratios]
increase_factor = origin_queries[1] / origin_queries[0]
# Original simplified model: one query per miss, no coalescing or retries.
# Results: [100, 400] queries/s, fourfold increase. Not an AWS quota or load test.Num ensaio fictício, o portal tem 98% de hits mas serve o relatório de outro cliente porque a origem recebe ClientId e a chave de cache não o distingue. A equipa contém a exposição e revê o contrato antes de otimizar a taxa de hits.
Armadilhas comuns
Confundir metadata encaminhada com chave; confiar só em no-store; aceitar média ou hit ratio como prova de correção; limpar toda a cache sem medir a origem.
Tópicos relacionados: Modernização e orquestração
A cache só melhora o serviço quando entrega a representação correta dentro do contrato de frescura e a origem suporta os misses.
Referência: CloudFront cache key · SAP-C02