Latência no serviço de câmbio: onde atacar primeiro
Uma squad do BB mantém um serviço de cotação de câmbio que atende 40 mil requisições por minuto em horário de pico. O SLA promete p99 abaixo de 300 ms, mas nas últimas três semanas o p99 subiu para 1.200 ms sempre entre 10h e 11h. O p50 permanece estável em 80 ms. O serviço roda em três pods Kubernetes atrás de um balanceador, consulta um cache Redis e, em caso de miss, chama uma API externa de cotações. Métricas mostram que a taxa de acerto do cache cai de 96% para 61% nesse intervalo, que a API externa responde em média 900 ms e que o pool de conexões do Redis está com 70% de uso. O time de infraestrutura afirma que CPU e memória dos pods estão abaixo de 50%. Nenhum deploy foi feito no período.
1. Diagnostique a causa provável do aumento do p99 e justifique por que o p50 permaneceu estável. Que evidência adicional você buscaria antes de concluir?
Read the worked answer
A causa provável é a queda da taxa de acerto do cache, que força um volume maior de chamadas à API externa, cuja latência média (900 ms) já é muito superior ao SLA de 300 ms. O p99 sobe porque a cauda é composta justamente pelas requisições que deram miss e pagaram o custo da chamada externa. O p50 fica estável porque a maioria das requisições continua acertando o cache e responde em cerca de 80 ms; a mediana é insensível a uma minoria lenta.
A evidência adicional necessária é a decomposição da latência por caminho (hit versus miss), a distribuição do tempo de resposta da API externa (não só a média, mas p95/p99), o TTL configurado no Redis e a chave de cache utilizada. É preciso descobrir por que o hit ratio caiu: TTL curto demais, chaves com alta cardinalidade, invalidação em massa ou expiração sincronizada. Também vale verificar o pool do Redis: 70% de uso não explica sozinho o salto, mas reduz a margem para absorver o aumento de requisições.
2. Proponha duas ações de curto prazo (sem reescrever o serviço) e uma de médio prazo, indicando o risco de cada uma.
Read the worked answer
Curto prazo 1: aumentar o TTL e revisar a granularidade das chaves de cache, para elevar o hit ratio. Risco: servir cotação levemente desatualizada, o que exige validar com o time de negócio qual defasagem é aceitável para câmbio.
Curto prazo 2: aplicar timeout agressivo e fallback na chamada à API externa, retornando a última cotação conhecida com marcação de staleness em vez de esperar 900 ms. Risco: respostas desatualizadas em momentos de volatilidade, além de mascarar a indisponibilidade do provedor.
Médio prazo: adotar circuit breaker com cache de contingência e pré-aquecimento de chaves, além de dimensionar o pool do Redis e monitorar o hit ratio como SLI. Risco: complexidade operacional adicional e necessidade de testes de carga para calibrar limites, evitando que o breaker abra por ruído e degrade o serviço sem necessidade.