Como você faz cache para cortar carga do DB a milhões de req/min?

Question

IT Interview Practice · Accepted Answer

Coloque uma camada de **cache-aside** (Redis/Memcached) na frente do DB para que as leituras batam na memória, dê às entradas um **TTL** e **invalide na escrita**, adicione **proteção contra stampede** para que uma chave fria não desencadeie uma thundering herd no DB, e espalhe **chaves quentes** por réplicas para que uma chave popular não derreta um único nó.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside vs read-through

No **cache-aside** o app verifica o cache; num miss ele lê o DB e popula o cache ele mesmo. No **read-through** a biblioteca de cache faz isso por você. De qualquer forma o objetivo é o mesmo: transformar uma consulta de DB de 5ms em um lookup de memória de 0,2ms, para que um cache com 95% de hit rate corte o tráfego de leitura do DB em **20×**. A milhões de req/min o DB simplesmente não consegue servir toda leitura — o cache é o que faz os números funcionarem.

## TTL + invalidação

Duas formas de manter o cache fresco, e você geralmente precisa de ambas. **TTL** limita o staleness — uma entrada expira após N segundos para que dados errados se autocorrijam. **Invalidação explícita** deleta/atualiza a chave na escrita para uma correção que não pode esperar o TTL. O bug clássico é cachear sem invalidação e servir dados stale por minutos; o mais sutil é invalidar *e* setar na mesma escrita, o que gera race.

## Proteção contra stampede e chaves quentes

- **Stampede (thundering herd):** quando uma chave quente expira, milhares de misses concorrentes batem no DB de uma vez e podem derrubá-lo. Corrija com um **lock/single-flight por chave** (apenas uma requisição recomputa, as outras esperam) ou **refresh antecipado/probabilístico** antes da expiração.
- **Chaves quentes:** uma chave (o perfil de uma celebridade) pode saturar a CPU/rede de um único nó Redis. Espalhe-a — replique a chave entre nós, ou adicione um pequeno cache local in-process na frente do Redis para os itens mais quentes.

## Perspectiva de entrevista

O entrevistador quer ver você pensar além de "adicionar Redis". Bom: cache-aside com TTL. Excelente: você nomeia **proteção contra stampede, estratégia de invalidação, tratamento de chaves quentes e o que acontece numa indisponibilidade de cache**. A armadilha é assumir que o cache está sempre no ar — se o Redis morre e todo miss cai no DB, você tem uma **cache-avalanche** que derruba o DB também.

## Trade-offs e modos de falha

- **Staleness vs carga:** TTL curto = fresco mas mais misses; TTL longo = menos misses mas mais stale. Ajuste por dado.
- **Cache avalanche:** muitas chaves expirando juntas (mesmo TTL) causa um pico de carga — adicione **jitter** aos TTLs.
- **Consistência:** cache e DB podem divergir; para leituras money-critical, leia o DB ou use write-through.
- **Eviction de memória:** sob pressão o Redis faz eviction por política (LRU/LFU); uma política errada descarta silenciosamente seu conjunto quente.

Cache-aside vs read-through

TTL + invalidação

Proteção contra stampede e chaves quentes

Perspectiva de entrevista

Trade-offs e modos de falha

Perguntas relacionadas