Estratégias de Cache com Redis Que Realmente Fizeram Diferença

5 min de leitura
rediscacheperformancebackendgolang

Cache é onde muitos backends conseguem o maior e mais barato ganho — e também onde muitos adquirem os bugs mais confusos. "Coloque Redis na frente do banco" é fácil de dizer e fácil de fazer mal. Isto é o que de fato funcionou para mim sob carga de leitura real, e os modos de falha que aprendi a projetar contra antes que me encontrassem em produção.

Cache-Aside É o Padrão por um Motivo

O padrão que pego primeiro é cache-aside (lazy loading): a aplicação é dona do cache. Numa leitura, checa o Redis; num miss, lê o banco, popula o cache, retorna. Escritas vão para o banco e invalidam (ou atualizam) o cache.

func (s *Service) GetProduct(ctx context.Context, id string) (*Product, error) {
	key := "product:" + id

	// 1. Try the cache
	if b, err := s.rdb.Get(ctx, key).Bytes(); err == nil {
		var p Product
		if json.Unmarshal(b, &p) == nil {
			return &p, nil
		}
	}

	// 2. Miss → source of truth
	p, err := s.repo.GetProduct(ctx, id)
	if err != nil {
		return nil, err
	}

	// 3. Populate for next time (fire-and-forget on cache errors)
	if b, err := json.Marshal(p); err == nil {
		s.rdb.Set(ctx, key, b, ttlWithJitter(10*time.Minute))
	}
	return p, nil
}

Duas coisas ali são deliberadas. Primeiro, um erro de cache nunca faz a requisição falhar — se o Redis está fora, caímos para o banco e continuamos servindo. O cache é uma otimização, não uma dependência; no momento em que ele vira load-bearing você construiu um sistema que cai quando seu cache cai. Segundo, o TTL tem jitter, o que importa mais do que parece.

TTLs com Jitter Previnem Expiração Sincronizada

Se você cacheia um lote de itens com um TTL idêntico de 10 minutos — digamos, tudo carregado na hora do deploy — todos expiram no mesmo segundo, e no segundo seguinte toda requisição é um miss martelando o banco simultaneamente. Espalhar as expirações por uma janela resolve:

func ttlWithJitter(base time.Duration) time.Duration {
	jitter := time.Duration(rand.Int63n(int64(base) / 5)) // up to +20%
	return base + jitter
}

Barato, e transforma um thundering herd sincronizado num fluxo suave de refreshes.

O Stampede Que Derruba o Banco

Jitter lida com muitas chaves expirando juntas. O caso mais desagradável é uma chave quente expirar. Imagine o cache do seu produto mais popular expirando durante o pico de tráfego: centenas de requisições concorrentes todas dão miss de uma vez, e todas rodam a mesma query cara para reconstruir o mesmo valor. O cache não reduziu a carga — ele a agrupou num pico mirado no seu banco.

O conserto é deixar só uma requisição reconstruir enquanto as outras esperam pelo resultado dela. Em Go, singleflight faz exatamente isso sem infraestrutura extra:

import "golang.org/x/sync/singleflight"

var group singleflight.Group

func (s *Service) getProductCoalesced(ctx context.Context, id string) (*Product, error) {
	v, err, _ := group.Do("product:"+id, func() (interface{}, error) {
		return s.repo.GetProduct(ctx, id) // only ONE of N concurrent callers runs this
	})
	if err != nil {
		return nil, err
	}
	return v.(*Product), nil
}

singleflight colapsa N chamadas concorrentes para a mesma chave numa execução e entrega a todos os callers o resultado compartilhado. Sob um miss de chave quente, seu banco vê uma query em vez de centenas. (Isso coalesce por-processo; para um lock verdadeiramente global entre muitas instâncias você usaria um lock de vida curta no Redis, ao custo de mais complexidade — raramente precisei ir tão longe.)

Invalidação: A Parte Difícil

Há uma piada velha de que os dois problemas difíceis da computação são invalidação de cache e dar nome às coisas. A piada está certa sobre o primeiro. As estratégias confortáveis, da pior à melhor em correção:

  • Só TTL — nunca invalidar explicitamente; tolerar staleness até o TTL. O mais simples, e ok quando leituras ligeiramente stale são aceitáveis (descrições de produto, config). A janela de staleness é uma decisão de produto, não técnica — consiga alguém para assinar embaixo de "até 10 minutos stale".
  • Invalidação write-through / write-around — a cada escrita, atualizar ou deletar a chave do cache. Mais fresco, mas agora seu caminho de escrita tem que saber toda chave que um dado alimenta, e se você esquecer uma, ele serve dado stale para sempre sem TTL para salvar.
  • Invalidação orientada a eventos — escritas emitem eventos de mudança; um consumidor invalida as chaves afetadas. Desacopla o caminho de escrita do conhecimento do cache, ao custo de infraestrutura real e frescor eventual (não imediato).

Eu default para só-TTL e só adiciono invalidação explícita para dados onde staleness genuinamente machuca, porque todo caminho de invalidação é uma nova forma de errar.

Trade-offs

Strategy         Freshness         Write-path cost    Failure mode
---------------  ---------------   ----------------   ---------------------------
TTL only         stale ≤ TTL       none               serves stale within window
Write invalidate fresh             couples write→keys stale forever if a key missed
Event-driven     near-fresh        infra + consumer   lag; more moving parts

O enquadramento que me mantém fora de encrenca: um cache é uma aposta de que leituras dominam escritas e que algum staleness é aceitável. Se leituras não dominam, o cache mal ajuda. Se nenhum staleness é aceitável, você não está realmente cacheando — está construindo uma segunda fonte da verdade, e isso é um problema muito mais difícil. Nomeie seu orçamento de staleness, mantenha o cache não-load-bearing, coalesça seus stampedes, e Redis na frente do Postgres é uma das coisas de melhor custo-benefício que você pode fazer a um serviço read-heavy.