Quais estratégias e padrões de cache existem com Redis?

Question

Accepted Answer

Além do básico cache-aside, existem várias **estratégias de cache** — cache-aside, write-through, write-behind, read-through — cada uma com diferentes trade-offs de consistência e desempenho. Entendê-las (e as políticas de evicção) ajuda você a projetar caching eficaz.

## Cache-aside (lazy loading — mais comum)

```text
App checks cache → miss → load from DB → populate cache → return.
  ✓ Only requested data is cached (efficient); resilient (works if cache is down)
  ✗ First request is a miss (slower); cache can be stale until TTL/invalidation
→ The default, most common strategy.
```

## Write-through e write-behind

```text
WRITE-THROUGH → write to cache AND DB together (synchronously) on every write
  ✓ Cache always fresh/consistent  ✗ Writes are slower (two writes); caches unread data

WRITE-BEHIND (write-back) → write to cache immediately, write to DB ASYNC later
  ✓ Fast writes  ✗ Risk of data loss if cache fails before the DB write; more complex
```

## Read-through

```text
READ-THROUGH → the cache layer itself loads from the DB on a miss (abstracted)
  → app just reads from the cache; the cache handles DB loading transparently
  (similar to cache-aside but the loading logic lives in the cache layer/library)
```

## Políticas de evicção (quando a memória está cheia)

```text
When Redis hits its memory limit (maxmemory), it EVICTS keys per a policy:
  LRU (Least Recently Used)  → evict least-recently-accessed (good general default)
  LFU (Least Frequently Used)→ evict least-frequently-accessed
  TTL-based (volatile-ttl)   → evict keys closest to expiry
  random / noeviction        → random, or reject writes when full
→ allkeys-lru is a common choice for a pure cache. Set maxmemory + a policy.
```

## Evitando problemas de cache

```text
✓ Cache STAMPEDE (many misses at once hammering the DB) → locking, staggered TTLs
✓ Stale data → appropriate TTLs + invalidation on writes
✓ Cache PENETRATION (querying non-existent keys) → cache negative results briefly
```

## Por que isso importa

Entender estratégias de cache é valioso para **projetar sistemas de cache eficazes**, construindo sobre cache-aside básico, portanto é conhecimento útil para trabalho focado em desempenho.

Enquanto cache-aside (lazy loading — verificar o cache, carregar do BD em caso de falha, preencher o cache) é o padrão comum, entender a **gama de estratégias** permite escolher a correta para a situação: **write-through** (escrever no cache e BD juntos para cache sempre fresco ao custo de escritas mais lentas), **write-behind** (escrever no cache imediatamente e no BD de forma assíncrona para escritas rápidas mas com risco de perda de dados), e **read-through** (a camada de cache carrega de forma transparente do BD) — cada uma com distintos trade-offs de consistência/desempenho que importam para diferentes requisitos de consistência e padrões de escrita.

Entender **políticas de evicção** (LRU, LFU, baseadas em TTL, etc. — como Redis decide quais chaves remover quando a memória está cheia) é importante para configurar Redis como um cache corretamente (definindo `maxmemory` e uma política apropriada como `allkeys-lru` para um cache puro), para que se comporte bem sob pressão de memória.

Saber como **evitar problemas comuns de cache** — **stampede** de cache (muitas falhas simultâneas martelando o banco de dados, mitigado por locking ou TTLs escalonados), **dados obsoletos** (gerenciados com TTLs e invalidação), e **penetração** de cache (queries repetidas para chaves inexistentes, mitigadas pelo cache de resultados negativos) — reflete design maturo de caching que evita problemas reais de produção.

Como caching eficaz impacta significativamente o desempenho e a estratégia/configuração correta depende do caso de uso, e já que entender as estratégias, políticas de evicção e armadilhas comuns permite projetar caching robusto, entender estratégias e padrões de cache é conhecimento valioso e praticamente relevante para engenharia de desempenho com Redis, elevando caching do padrão básico para sistemas bem-projetados que tratam consistência, memória e modos de falha corretamente.