Padrões de Cache

Colocar um cache na frente de um banco levanta duas perguntas que não têm nada a ver com o Redis em si: quem preenche o cache quando um valor está faltando, e o que acontece com o cache quando o dado é escrito. As respostas formam um pequeno conjunto de padrões com nome. Vale a pena conhecê-los pelo nome: numa revisão de arquitetura ou numa entrevista, "cache-aside com remoção na escrita e TTL de 5 minutos" diz numa frase o que de outro jeito levaria um parágrafo².

Ao longo da página o exemplo é o serviço catalog da BoxOffice: GET /events/{id} devolve um evento com o local e a tabela de preços, e os organizadores ocasionalmente editam um evento com PUT /events/{id}.

Cache-aside

Cache-aside (também chamado de lazy loading, carregamento preguiçoso) é o padrão default e o que você deve supor, a não ser que haja um motivo para outro. A aplicação conversa com o cache e com o banco; o cache é um armazenamento chave-valor passivo que não sabe nada sobre o banco¹.

sequenceDiagram
    participant A as serviço catalog
    participant R as Redis
    participant D as PostgreSQL
    A->>R: GET event:42
    R-->>A: nil (falta)
    A->>D: SELECT evento, local, preços WHERE id = 42
    D-->>A: linha
    A->>R: SET event:42 json EX 300
    A->>R: GET event:42 (próxima requisição)
    R-->>A: json (acerto)

Caminho de leitura: procure no cache; num acerto, devolva; numa falta, leia o banco, guarde o resultado com um TTL e devolva. Caminho de escrita: atualize o banco e então remova a chave (não a atualize — veja Invalidação). A próxima leitura a preenche de novo.

Por que ele é o default:

• Só o que é lido vai para o cache — nada de memória desperdiçada com dados que ninguém pede.
• O cache é opcional: se o Redis cair, as leituras vão ao banco (mais lento, mas correto). A aplicação continua funcionando, desde que o banco aguente a carga.
• Simples de entender: o banco é sempre a fonte da verdade — o cache guarda dados derivados, que podem ser reconstruídos a qualquer momento³.

Seus custos:

• A primeira leitura de cada chave é lenta (falta + banco + SET): três idas e voltas em vez de uma.
• Janela de defasagem: entre a escrita no banco e a remoção, e em algumas condições de corrida (Invalidação), leitores podem ver um valor antigo — limitado pelo TTL.
• A lógica de cache fica espalhada pelo código da aplicação — a não ser que um framework a esconda.

Cache-aside no Spring Boot

A abstração de cache do Spring implementa cache-aside com anotações: @Cacheable envolve o caminho de leitura, @CacheEvict a remoção na escrita. É o jeito mais curto de escrever o padrão num serviço Spring; o Hands-on 5 o escreve à mão, para que cada passo possa ser visto e medido (quadro abaixo).

@Service
public class EventService {

    private final EventRepository repository;

    public EventService(EventRepository repository) {
        this.repository = repository;
    }

    // Read path: key "events::42"; runs the method only on a miss
    @Cacheable(cacheNames = "events", key = "#id", unless = "#result == null")
    public EventDto findById(long id) {
        return repository.findWithVenueAndPrices(id)
                .map(EventDto::from)
                .orElse(null);
    }

    // Write path: update the database first, then delete the key
    @Transactional
    @CacheEvict(cacheNames = "events", key = "#id")
    public EventDto update(long id, EventUpdate change) {
        Event event = repository.findById(id).orElseThrow();
        event.apply(change);
        return EventDto.from(repository.save(event));
    }
}

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory factory) {
        RedisCacheConfiguration defaults = RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofMinutes(5))
                .disableCachingNullValues()
                .serializeValuesWith(RedisSerializationContext.SerializationPair
                        .fromSerializer(RedisSerializer.json()));

        return RedisCacheManager.builder(factory)
                .cacheDefaults(defaults)
                .withCacheConfiguration("events", defaults.entryTtl(Duration.ofMinutes(5)))
                .withCacheConfiguration("prices", defaults.entryTtl(Duration.ofSeconds(30)))
                .build();
    }
}

public Result get(String key, Duration ttl, Supplier<?> loader) {
    if (!enabled) {
        return count(new Result(toJson(loader.get()), "BYPASS"));
    }
    var cached = read(key);
    if (cached != null) {
        return count(new Result(cached, "HIT"));
    }
    return count(load(key, ttl, loader));
}
private Result load(String key, Duration ttl, Supplier<?> loader) {
    var json = toJson(loader.get());
    try {
        redis.opsForValue().set(key, json, withJitter(ttl));
    } catch (DataAccessException e) {
        log.warn("cache write failed for {}: {}", key, e.getMessage());
    }
    return new Result(json, "MISS");
}

private String read(String key) {
    try {
        return redis.opsForValue().get(key);
    } catch (DataAccessException e) {
        // Redis down or slow: the cache is an optimization, not a dependency
        log.warn("cache read failed for {}: {}", key, e.getMessage());
        return null;
    }
}

Cache-aside à mão (Python)

Sem framework, o padrão cabe numa dúzia de linhas. É o que o @Cacheable faz por trás:

import json
import redis

r = redis.Redis(host="redis", port=6379, decode_responses=True)
TTL_SECONDS = 300


def get_event(event_id: int, db) -> dict | None:
    key = f"boxoffice:catalog:event:{event_id}:v3"
    cached = r.get(key)
    if cached is not None:                       # hit
        return json.loads(cached)
    event = db.fetch_event_with_venue_and_prices(event_id)   # miss → source of truth
    if event is not None:
        r.set(key, json.dumps(event), ex=TTL_SECONDS)
    return event


def update_event(event_id: int, change: dict, db) -> None:
    db.update_event(event_id, change)            # 1. commit to the database
    r.delete(f"boxoffice:catalog:event:{event_id}:v3")   # 2. then invalidate

Read-through

No read-through, a aplicação só conversa com o cache. Numa falta, o próprio cache carrega o valor do banco, usando uma função loader que você registra. A lógica sai da aplicação e vai para a camada de cache.

sequenceDiagram
    participant A as serviço catalog
    participant C as Cache com loader
    participant D as PostgreSQL
    A->>C: get(42)
    C->>D: loader(42): SELECT ...
    D-->>C: linha
    C-->>A: valor (agora no cache)
    A->>C: get(42)
    C-->>A: valor (acerto)

Caches em processo implementam isso nativamente — o LoadingCache do Caffeine, o Guava, o MemoryCache do .NET com uma factory. Caches distribuídos raramente implementam (o Redis não faz ideia de como consultar o PostgreSQL), então "Redis read-through" na prática é uma biblioteca na aplicação que se comporta como se fosse o cache.

LoadingCache<Long, Venue> venues = Caffeine.newBuilder()
        .maximumSize(10_000)
        .expireAfterWrite(Duration.ofMinutes(10))
        .build(id -> venueRepository.findById(id).orElse(null));   // the loader

Venue v = venues.get(7L);   // miss → loader runs once, even with 100 concurrent callers

Uma propriedade útil: um bom cache read-through agrupa (coalesce) faltas concorrentes na mesma chave — 100 threads pedindo o local 7 disparam uma única chamada ao loader. É a cura para o stampede descrito em Modos de Falha.

Write-through

No write-through, toda escrita vai para o cache e para o banco como parte da mesma operação, antes de o cliente receber a resposta. O cache fica sempre aquecido com o último valor de cada chave escrita.

sequenceDiagram
    participant A as serviço catalog
    participant C as Cache
    participant D as PostgreSQL
    A->>C: put(42, evento novo)
    C->>D: UPDATE events SET ... WHERE id = 42
    D-->>C: ok
    C-->>A: ok (cache e banco atualizados)

• Bom: leituras logo após uma escrita acertam o cache com o valor novo (read-your-writes através do cache); sem penalidade de falta depois de atualizações.
• Ruim: toda escrita paga duas latências; valores escritos e nunca lidos ainda ocupam memória (combine com um TTL); as duas escritas não são atômicas — se a escrita no banco falha depois da escrita no cache, o cache guarda um valor que nunca existiu. Escreva primeiro no banco e remova a chave se algo falhar.

Write-through serve para dados lidos logo depois de escritos: o perfil do usuário depois da edição, o painel do organizador.

Write-behind

O write-behind (ou write-back) confirma a escrita assim que o cache a recebe e persiste no banco depois, de forma assíncrona, muitas vezes em lotes.

sequenceDiagram
    participant A as serviço
    participant C as Cache
    participant W as Descarregador
    participant D as PostgreSQL
    A->>C: INCR views:event:42
    C-->>A: ok (rápido, em memória)
    A->>C: INCR views:event:42
    C-->>A: ok
    W->>C: a cada 10 s: lê e zera os contadores
    W->>D: UPDATE event_stats SET views = views + 1834

• Bom: escritas tão rápidas quanto a memória; muitas escritas na mesma chave são agrupadas numa única escrita no banco; o banco fica protegido de rajadas de escrita.
• Ruim: escritas confirmadas podem ser perdidas se o nó do cache morrer antes de descarregar; o banco está sempre atrasado; a ordem e as falhas do descarregador exigem engenharia cuidadosa.

Use só para dados em que perder alguns segundos de escritas é aceitável: contadores de visualização, "pessoas olhando este evento agora", eventos de analytics, contadores de rate limit. Nunca para pedidos, pagamentos ou reservas de assento.

Write-around

No write-around, as escritas vão direto para o banco e o cache não é tocado (ou a chave é simplesmente removida). O valor só entra no cache quando alguém o lê.

É o que o cache-aside faz no caminho de escrita, e é a escolha certa quando o dado escrito raramente é lido logo em seguida: o ingresso que um fã acabou de comprar (lido poucas vezes, por uma só pessoa), logs de auditoria, histórico de pedidos. Escrever isso no cache só despejaria entradas úteis.

Refresh-ahead

O refresh-ahead recarrega uma entrada quente antes de ela expirar, para que os leitores nunca vejam a falta. Uma tarefa em segundo plano (ou o primeiro leitor depois de um limiar, por exemplo quando 80% do TTL já passou) busca o valor novo enquanto o atual continua sendo servido.

sequenceDiagram
    participant A as Leitor
    participant C as Cache
    participant D as PostgreSQL
    A->>C: get(event:42), TTL 300 s, idade 250 s
    C-->>A: valor atual (servido na hora)
    C->>D: recarga assíncrona (idade > 80% do TTL)
    D-->>C: valor novo, TTL volta a 300 s

• Bom: chaves quentes nunca expiram sob carga — sem pico de latência, sem stampede.
• Ruim: se a previsão estiver errada, o cache atualiza chaves que ninguém vai ler (carga desperdiçada no banco). Funciona melhor para um conjunto pequeno e conhecido de chaves quentes — como os eventos que abrem vendas hoje.

O Caffeine implementa isso com refreshAfterWrite; a versão probabilística, que dispensa tarefa em segundo plano, é o XFetch (Modos de Falha). Uma ideia parecida no HTTP é o Cache-Control: stale-while-revalidate, que permite à CDN servir a cópia antiga enquanto busca uma nova.

Comparando os padrões

Na prática, os sistemas combinam os padrões: cache-aside + write-around (remoção na escrita) é a base comum; refresh-ahead é acrescentado para as poucas chaves mais quentes; write-behind fica reservado para contadores.

Desenhando chaves e valores do cache

Os padrões dizem quando ler e escrever no cache; o desenho de chaves e valores decide se ele funciona em escala.

Chaves estruturadas, com namespace. Use um prefixo por serviço e entidade, e inclua tudo que muda a resposta:

boxoffice:catalog:event:42:v3                 # one event, schema version 3
boxoffice:catalog:prices:42:BRL               # price table in a given currency
boxoffice:search:q=rock+sp:page=1:lang=pt     # a search result page
boxoffice:session:9f1c2e...                   # a session

• Versão na chave (:v3): quando o formato do objeto muda num deploy, incremente a versão — réplicas antigas e novas deixam de ler os valores incompatíveis umas das outras, e as chaves antigas simplesmente expiram.
• Tudo que muda o resultado precisa estar na chave: idioma, moeda, página, permissões do usuário. Esquecer um item é como uma página em português acaba servida a um usuário de inglês — ou os dados de um usuário a outro.
• Chaves curtas, mas legíveis; evite entrada de usuário sem limite nas chaves (normalize e aplique hash em consultas de busca longas).

O que cachear.

Valores. JSON é legível e fácil de depurar; formatos binários (Protocol Buffers, MessagePack, Kryo) são menores e mais rápidos de interpretar. Comprima valores acima de alguns kilobytes (por exemplo, com LZ4 ou Zstandard). Valores grandes atrapalham mais do que parece: um valor de 1 MB leva ~1 ms de transferência de rede por leitura num link de 10 Gbit/s e bloqueia o Redis enquanto é copiado (Modos de Falha — chaves grandes).

Cache negativo. Se GET /events/999999 não existe, cacheie também a ausência (um sentinela como "∅" com TTL curto, por exemplo 30 s). Caso contrário, toda requisição a um id inexistente — vinda de um bug ou de um bot — vai direto ao banco. Essa é a primeira defesa contra a penetração de cache.

Cache em dois níveis (near cache)

Cada réplica do serviço catalog pode manter um pequeno cache em processo (L1) na frente do Redis compartilhado (L2):

flowchart LR
    REQ["requisição"] --> L1["L1: Caffeine<br/>na JVM, ~1 µs"]
    L1 -->|"falta"| L2[("L2: Redis<br/>compartilhado, ~0,5 ms")]
    L2 -->|"falta"| DB[("PostgreSQL<br/>~5 ms")]
    DB --> L2
    L2 --> L1

• Por quê: um acerto no L1 custa uma consulta a um hash map (microssegundos, sem rede), e ele absorve chaves quentes que de outro modo martelariam um único shard do Redis (Modos de Falha — chaves quentes).
• O problema — invalidação: com 20 réplicas, uma escrita precisa invalidar 20 caches L1 privados mais o Redis. Opções: um TTL bem curto no L1 (1–5 s), aceitando essa defasagem; ou difundir as invalidações pelo pub/sub do Redis (ou pelo client-side caching do Redis com rastreamento, CLIENT TRACKING) para que cada réplica descarte sua cópia local.

Como se conecta

flowchart LR
    CA["cache-aside<br/>a app preenche no miss"] --> INV["apagar após o commit<br/>→ Invalidação"]
    RT["read-through<br/>a biblioteca do cache carrega"] --> INV
    WA["write-around<br/>escreve no banco, pula o cache"] --> CA
    WT["write-through<br/>cache e banco juntos"] --> FRESH["leituras frescas,<br/>escritas mais lentas"]
    WB["write-behind<br/>grava depois, em lotes"] --> LOSS["pode perder escritas confirmadas:<br/>contadores sim, assentos nunca"]
    LOSS -.-> TX["reservas ficam no SQL<br/>→ Bancos de dados"]
    RA["refresh-ahead"] --> STAMP["sem picos na expiração<br/>→ Modos de falha"]
    KEYS["chaves: namespace,<br/>versão, valores pequenos"] --> CA
    L1["cache em dois níveis<br/>L1 Caffeine + Redis"] --> HOT["chaves quentes<br/>→ Modos de falha"]

Componentes da paleta: cache (Redis, a cópia compartilhada) · app (o catalog roda cache-aside e mantém um L1 Caffeine por réplica) · sql (a fonte da verdade por trás de todo padrão) · worker (o processo que grava os contadores do write-behind) · pubsub (avisa cada cópia L1 para descartar uma chave). Cenários: read-heavy-cache, search-autocomplete. Continua em: Invalidação e Despejo, Modos de Falha, Bancos de dados — o bug da venda duplicada, Hands-on 5, Exercício: cache + banco.