O que cachear numa integração, e o que nunca

Cache mal colocado é pior que cache nenhum: ele esconde o erro, entrega dado velho como se fosse novo, e quando dá problema ninguém desconfia dele primeiro.

A decisão certa vem de uma pergunta só: qual é o custo de esta informação estar desatualizada por um minuto?

O que cachear sem pensar duas vezes

Catálogo. Lista de países, de serviços, de opções disponíveis. Muda em escala de semanas e é consultado a cada operação.

Buscar a lista inteira antes de cada pedido é o desperdício mais comum em integração de infraestrutura. Some latência de rede ao seu fluxo, gasta cota, e devolve quase sempre a mesma coisa.

Guarde por horas. Se um país novo demorar duas horas para aparecer, ninguém se machuca.

Metadados que você mapeia. Os identificadores de país e serviço que você precisa para montar o pedido. Consulte uma vez, guarde, e atualize periodicamente — não a cada chamada.

Respostas de documentação e conteúdo público. Página que não muda por usuário.

O que nunca cachear

Saldo. Mostrar saldo velho leva o cliente a fazer um pedido que vai falhar, ou a achar que foi cobrado errado. É a informação que mais gera chamado quando está desatualizada.

Status de pedido em andamento. O ponto do status é justamente mudar. Cache aqui produz a tela que diz "aguardando" depois de o código já ter chegado.

Qualquer coisa por usuário, em cache compartilhado. É como um cliente vê o dado de outro. Se precisar cachear por usuário, a chave precisa incluir o identificador dele — e mesmo assim, pense duas vezes.

Resposta de erro. Cachear um erro transitório transforma uma falha de dois segundos numa falha de dez minutos.

O caso ambíguo: preço

Preço fica no meio, e a decisão depende do que você faz com ele.

Para exibir uma lista, cache curto é razoável. O cliente está navegando.

Para cobrar, nunca. O valor debitado precisa vir da fonte, no momento da operação. Preço de tela e preço de cobrança podem divergir por segundos — e o que vale é o segundo.

O erro que gera reclamação é usar o valor cacheado da tela como valor do débito. O cliente viu três reais, foi cobrado três e vinte, e você não consegue explicar.

Invalide por evento, não só por tempo

Prazo de expiração é o mínimo. Melhor é apagar a entrada quando o dado muda.

Alterou o catálogo pelo painel? Apague a chave do catálogo. Assim o prazo vira rede de segurança, não o único mecanismo.

Sem isso, você fica preso entre prazo curto — que anula o ganho — e prazo longo — que atrasa toda correção.

Falha de cache não pode virar falha do sistema

Se o cache está fora do ar, a aplicação deve buscar na origem e seguir. Cache é otimização, não dependência.

Isso parece óbvio e quebra com frequência: uma chamada de leitura sem tratamento de erro derruba a requisição inteira quando o serviço de cache oscila. O resultado é uma indisponibilidade causada pela peça que existia para melhorar o desempenho.

Envolva a leitura, trate a falha como ausência, e siga.

Guarde o negativo com cuidado

Se a consulta não encontrou nada, cachear a ausência evita bater na origem repetidamente por algo que não existe.

O cuidado é o prazo: ausência costuma virar existência. Item que passou a existir e continua "não encontrado" por dez minutos é um bug difícil de rastrear, porque some quando você testa.

Prazo bem mais curto para o negativo que para o positivo.

Um teste que revela cache errado

Mude o dado na origem e cronometre quanto tempo leva para aparecer.

Se a resposta for maior do que você aceitaria explicar a um cliente, o prazo está errado — ou falta invalidação por evento.

E se você não souber responder onde aquilo está cacheado, esse é o problema maior: cache que ninguém sabe onde fica é cache que ninguém consegue limpar no incidente.

Se o motivo para cachear é bater no limite de requisições, vale ler antes 429: como repetir sem piorar — reduzir chamada inútil costuma resolver mais que ajustar retentativa.

Na API de números virtuais, as listas de países e de serviços mudam devagar e são boas candidatas a cache; o preço vale consultar na hora da compra.