Conceito e mecanismo
Uma cache melhora desempenho apenas quando reutiliza a resposta certa para o pedido certo. Se o resultado varia por tenant e a cache key omite essa dimensão, pedidos diferentes podem receber a mesma resposta. A primeira decisão é impedir partilha incorreta. Depois define que respostas podem ser guardadas, que variantes precisam de separação e como se valida autorização. Um identificador de tenant fornecido pelo cliente não substitui controlo de acesso. Para dados privados, pode ser necessário desativar cache no comportamento relevante. A melhoria de hit ratio deve ser avaliada dentro destas condições, não como objetivo isolado.
Aplicação guiada
Uma fila também muda o problema em vez de o eliminar. SQS standard pode entregar novamente uma mensagem, pelo que um movimento de negócio precisa de idempotência durável quando a repetição não é aceitável. Guardar IDs só na memória não sobrevive à falha do worker. Dimensiona consumidores e dependências para a idade máxima do trabalho pendente. Se uma API tem CPU baixa mas espera por ligações à base de dados, investiga o pool e as consultas antes de duplicar frontends. Compara arquiteturas pelo custo total sob os mesmos requisitos: computação mais barata pode acrescentar tráfego, apoio noturno e trabalho de recuperação. Usa valores observados ou estimativas declaradas, sem transformar preços isolados em promessa de poupança.
O worker confirmou o movimento e caiu antes de eliminar a mensagem. O identificador de negócio permite reconhecer a repetição sem aplicar novo movimento.
Armadilhas comuns
Cache key como autorização; entrega como efeito único; fila como garantia de prazo; CPU média como diagnóstico completo.
Tópicos relacionados: Operação, evidência e remediação · Melhoria, custos e ciclo de vida
Relaciona cada otimização com correção dos dados, comportamento sob falha e custo total.
Referência: SAP-C02 content domain 2 · SAP-C02