Projetando um Cache Distribuído: Guia Completo de System Design

Em escala pequena, cache parece atalho. Em produção, cache vira sistema distribuído. Ele tem pressão de memória, regras de roteamento, dados stale, comportamento de cliente, falhas parciais, segurança, custo e operação. O erro comum é tratar Redis ou Memcached como camada mágica de velocidade. O modelo mental correto é mais rígido:

• banco de dados guarda a verdade durável,
• cache guarda aceleração temporária,
• clientes precisam de fallback cuidadoso,
• plataforma precisa controlar invalidação, capacidade e visibilidade.

Cache distribuído bom reduz latência e carga no banco sem virar fonte oculta de verdade. Este artigo desenha esse sistema de ponta a ponta. Redis e Memcached aparecem juntos porque ambos continuam relevantes. Redis oferece estruturas ricas, replicação, persistência opcional, Lua/functions, streams, sorted sets e Redis Cluster. Memcached oferece um cache key-value em memória simples, rápido e normalmente shardado no cliente. Nenhum deles elimina design.

Sumário

• Análise de Requisitos
• Cálculos de Envelope
• Arquitetura de Alto Nível
• Design de API
• Modelagem de Dados
• Padrões Centrais de Cache
• Sharding e Roteamento
• Hash Slots no Redis Cluster
• Memcached em Escala
• Replicação e Failover
• Cache Multi-Região
• Invalidação e Estratégia de TTL
• Eviction e Gestão de Memória
• Semântica de Consistência
• Mitigação de Hot Keys
• Thundering Herd e Prevenção de Dogpile
• Negative Caching e Admission Control
• Confiabilidade e Degradação
• Segurança
• Observabilidade e SLOs
• Dicas de Entrevista
• Anti-Patterns
• Conclusão
• Referências
• Referência Rápida

Análise de Requisitos

A primeira decisão em entrevista é escopo. Não comece por Redis. Comece pelo workload.

Requisitos Funcionais

1. Servir objetos lidos com frequência com latência menor que a fonte de verdade.
2. Reduzir pressão de leitura em bancos primários e APIs downstream.
3. Suportar leituras e escritas key-value para objetos serializados.
4. Suportar expiração por TTL.
5. Suportar invalidação explícita depois de writes.
6. Suportar fallback seguro em cache miss ou falha do cache.
7. Suportar escala horizontal entre nós de cache.
8. Suportar chaves de alta cardinalidade sem posicionamento manual.
9. Suportar mitigação de hot keys.
10. Expor métricas de hit rate, latência, memória, evictions e erros.
11. Suportar controle de acesso e transporte criptografado quando necessário.
12. Manter comportamento previsível durante deploys, failovers e resharding.

Requisitos Não Funcionais

Perguntas de Clarificação

1. Quais dados podem ser cacheados?
2. Quanto stale cada objeto pode ficar?
3. Cache é local a um serviço ou compartilhado por vários serviços?
4. Read-through mora numa biblioteca, proxy ou aplicação?
5. Qual distribuição de tamanho dos objetos?
6. Qual QPS de pico e qual QPS de miss?
7. O que acontece se o cache cair?
8. Consistência cross-region é obrigatória?
9. Dados exigem criptografia ou isolamento forte?
10. Writes são frequentes o suficiente para complicar invalidação?

Premissas Deste Design

Este desenho assume:

• produto SaaS multi-tenant,
• workload read-heavy,
• deploy regional de aplicações,
• Redis Cluster para casos com recursos ricos,
• pool Memcached para cache simples de objetos,
• banco relacional como fonte de verdade,
• Kafka ou equivalente para eventos de invalidação,
• meta de p99 abaixo de 150ms em APIs de usuário,
• budget de staleness de 30 segundos para perfis e catálogo,
• política de não cachear decisões críticas de autorização sem versionamento explícito.

O Que Este Cache Não É

Cache não é banco primário. Cache não é log de auditoria. Cache não é ledger de pagamento. Cache não é a única cópia de estado de usuário. Cache pode esquecer. Esquecer é recurso quando a fonte de verdade continua correta. Esquecer é incidente quando o cache virou banco sem ninguém admitir.

Cálculos de Envelope

Declare premissas antes de números. O número exato importa menos que o formato da pressão.

Escala Assumida

Usuários ativos mensais: 80 milhões
Usuários ativos diários: 20 milhões
Requests de API no pico: 1.200.000/s
Requests médios de API: 250.000/s
Percentual de leitura cacheável: 65%
Hit rate alvo: 90%
Tamanho médio de objeto cacheado: 2 KB
P95 de objeto cacheado: 12 KB
Objetos quentes possíveis: 250 milhões de chaves
Objetos alterados por dia: 40 milhões
Regiões: 3 ativas

Carga de Requests

Leituras cacheáveis no pico = 1.200.000 * 0,65
                            = 780.000 leituras/s
Com hit rate de 90%:
cache hits/s = 702.000
cache misses/s = 78.000

78.000 leituras por segundo no banco ainda é muito. O caminho de miss precisa de proteção. O cache deve reduzir carga média e limitar amplificação em miss.

Estimativa de Memória

Objetos quentes lógicos: 250.000.000
Payload médio: 2 KB
Overhead de metadados e allocator: 35%
Fator de replicação: 2
Payload bruto = 250M * 2KB
              ~= 500 GB
Com overhead = 500GB * 1,35
             ~= 675 GB
Com uma réplica = 675GB * 2
                ~= 1,35 TB

Essa é estimativa direcional. Memória real no Redis muda com encoding, tamanho de chave, tipo de objeto, fragmentação, buffers de replicação e buffers de persistência. Memória real no Memcached depende de slab classes, distribuição de tamanho e espaço desperdiçado em chunks.

Estimativa de Rede

Banda de cache hit no pico ~= 702.000 * 2KB
                           ~= 1,4 GB/s de payload
Com overhead de protocolo, TLS e objetos p95:
planeje múltiplos GB/s dentro da região.

Rede não é detalhe. Cache pode mover gargalo de CPU do banco para NICs, conexões de cliente ou custo cross-AZ.

Estimativa de Miss Storm

Se deploy limpa 30% das chaves quentes no pico:

novo miss rate = misses normais + chaves frias
miss QPS normal = 78.000
leitura fria extra = 780.000 * 0,30
                   = 234.000
miss QPS total = 312.000

Se cada miss abre 3 queries:

QPS no banco = 936.000

Isso pode derrubar a fonte de verdade. Warming, request coalescing, TTL com jitter e admission control não são opcionais em escala alta.

Insight Central

Design de cache distribuído é design para limitar dano em miss. O caminho feliz é simples. O caminho de miss decide se o sistema sobrevive.

Arquitetura de Alto Nível

Princípios de Arquitetura

1. Mantenha leitura correta sem cache.
2. Deixe uso de cache explícito no limite do serviço.
3. Centralize construção de chaves em uma biblioteca.
4. Use cache local só para objetos pequenos, seguros e curtos.
5. Use cache distribuído para objetos quentes compartilhados.
6. Use invalidação por evento para famílias com muita escrita.
7. Use TTL como rede de segurança, não como única correção.
8. Proteja misses com coalescing e backpressure.
9. Trate hot key como problema central de capacidade.
10. Meça frescor, não só hit rate.

Escolha de Cache por Workload

Design de API

API de cache distribuído tem duas camadas:

• abstração usada pela aplicação,
• operações usadas pela infraestrutura.

A aplicação não deveria conhecer todo comando Redis. A plataforma não deveria esconder semânticas como TTL, stale tolerance e negative caching.

Interface do Cliente

export type CacheKey = string;
export type CachePolicy = {
  ttlSeconds: number;
  staleWhileRevalidateSeconds?: number;
  negativeTtlSeconds?: number;
  jitterRatio?: number;
  namespace: string;
  version: string;
  allowStaleOnError: boolean;
  maxSerializedBytes: number;
};
export type CacheResult<T> =
  | { status: "hit"; value: T; ageMs: number }
  | { status: "miss" }
  | { status: "stale"; value: T; ageMs: number; reason: "refreshing" | "origin_error" };
export interface DistributedCache {
  get<T>(key: CacheKey, policy: CachePolicy): Promise<CacheResult<T>>;
  set<T>(key: CacheKey, value: T, policy: CachePolicy): Promise<void>;
  delete(key: CacheKey): Promise<void>;
  getOrLoad<T>(
    key: CacheKey,
    policy: CachePolicy,
    loader: () => Promise<T | null>
  ): Promise<T | null>;
}

Exemplo no Serviço

async function getProductPage(productId: string, viewerRegion: string) {
  const key = cacheKeys.productPage(productId, viewerRegion);
  return cache.getOrLoad(
    key,
    {
      namespace: "catalog",
      version: "v4",
      ttlSeconds: 900,
      staleWhileRevalidateSeconds: 60,
      negativeTtlSeconds: 30,
      jitterRatio: 0.15,
      allowStaleOnError: true,
      maxSerializedBytes: 64 * 1024
    },
    async () => {
      const product = await productRepository.findRenderableProduct(productId, viewerRegion);
      return product ?? null;
    }
  );
}

Exemplos de Comandos Redis

Use comandos como vocabulário operacional. Não espalhe comando cru por todo serviço.

SET catalog:v4:product:us-east-1:123 "{...json...}" EX 900
GET catalog:v4:product:us-east-1:123
DEL catalog:v4:product:us-east-1:123
MGET catalog:v4:product:us-east-1:123 catalog:v4:product:us-east-1:456
INCRBY metrics:v1:product:123:views 1
EXPIRE metrics:v1:product:123:views 3600

Exemplos de Comandos Memcached

set catalog:v4:product:us-east-1:123 0 900 128
{"id":"123","name":"Keyboard","price":12900}
get catalog:v4:product:us-east-1:123
delete catalog:v4:product:us-east-1:123
add lock:v1:product:123 0 10 1
1

Exemplo SQL da Fonte de Verdade

SELECT
  p.id,
  p.name,
  p.price_cents,
  p.status,
  p.updated_at,
  i.available_quantity
FROM products p
JOIN inventory i ON i.product_id = p.id
WHERE p.id = $1
  AND p.status = 'active';

Modelagem de Dados

Modelagem de cache começa por chave. Chave ruim cria stale data, vazamento cross-tenant, partição quente e migração dolorosa.

Anatomia da Chave

<namespace>:<schema-version>:<tenant-ou-regiao>:<entity>:<id>:<variant>

Exemplo:

catalog:v4:tenant_42:product:123:currency_usd
profile:v2:tenant_42:user:9001:public
permissions:v8:tenant_42:user:9001:resource:invoice_77
negative:v1:tenant_42:product:missing_123

Regras de Chave

1. Inclua tenant ou fronteira de isolamento.
2. Inclua versão de schema.
3. Inclua região quando a região muda resposta.
4. Inclua segmento de viewer quando personalização muda resposta.
5. Mantenha chaves curtas para reduzir gasto de memória.
6. Evite strings livres vindas do usuário.
7. Evite chaves que exigem scan global.
8. Evite dados sensíveis em texto claro na chave.
9. Prefira builders determinísticos a concatenação manual.
10. Use versão para migração em vez de delete massivo quando possível.

Envelope do Valor Cacheado

type CacheEnvelope<T> = {
  payload: T;
  createdAtEpochMs: number;
  sourceVersion: string;
  entityUpdatedAtEpochMs?: number;
  softTtlEpochMs?: number;
  hardTtlEpochMs: number;
  compression?: "none" | "zstd" | "gzip";
};

Envelope permite decidir frescor depois do get. Também ajuda quando invalidação falha parcialmente.

Classes de Objeto

Serialização

JSON é fácil de depurar. MessagePack, Protobuf ou FlatBuffers reduzem payload e CPU em alguns casos. Compressão ajuda valores grandes, mas custa CPU e latência. Regra prática:

• não comprima objetos pequenos,
• avalie compressão acima de 4-8 KB,
• meça CPU antes de ligar globalmente,
• guarde codec no envelope,
• preserve compatibilidade em rolling deploy.

Padrões Centrais de Cache

Cache-Aside

Cache-aside é o padrão mais comum. A aplicação controla miss.

Benefícios:

• simples,
• explícito,
• resiliente quando cache falha,
• funciona com Redis e Memcached,
• entra bem em sistemas existentes.

Custos:

• lógica de miss repetida,
• TTL fácil de esquecer,
• risco de stampede,
• stale até TTL ou invalidação.

Read-Through

Read-through move o carregamento para biblioteca ou camada de cache. Simplifica aplicação. Também esconde chamadas à origem atrás da semântica de cache. Use quando a plataforma padroniza:

• construção de chave,
• loader,
• política de TTL,
• coalescing,
• métricas,
• comportamento stale.

Evite quando chamadores precisam de regras de consistência diferentes.

Write-Through

Write-through atualiza cache e fonte no caminho do request.

Write-through reduz leitura stale após write. Também aumenta latência de escrita. Ainda pode errar se ordem de commit e cache for mal definida. O commit no banco deve continuar autoritativo.

Write-Behind

Write-behind grava cache primeiro e persiste depois. É perigoso para dado de negócio normal. Use só quando perda é aceitável ou existe fila durável. Exemplos:

• contadores efêmeros,
• agregação de telemetria,
• métricas derivadas de baixo valor,
• writes bufferizados por log append-only.

Nunca use cache write-behind simples para saldo, pedido, permissão ou auditoria.

Refresh-Ahead

Refresh-ahead renova chaves quentes antes de expirar. Reduz tail latency para objetos previsíveis. Pode desperdiçar origem se aplicado sem critério. Use para:

• home page,
• páginas críticas de catálogo,
• configuração de tenant muito lida,
• chaves com popularidade estável.

Sharding e Roteamento

Um nó de cache é gargalo vertical. Cache distribuído exige roteamento.

Opções de Roteamento

Consistent Hashing

Consistent hashing reduz movimento de chaves quando nós mudam. Não elimina movimento. Sistemas grandes usam virtual nodes ou pesos para suavizar distribuição.

Rendezvous Hashing

Rendezvous hashing calcula score por nó e escolhe o maior. É simples e funciona bem em bibliotecas de cliente.

function pickNode(key: string, nodes: string[]): string {
  let bestNode = nodes[0];
  let bestScore = Number.NEGATIVE_INFINITY;
  for (const node of nodes) {
    const score = hash64(`${key}:${node}`);
    if (score > bestScore) {
      bestScore = score;
      bestNode = node;
    }
  }
  return bestNode;
}

Padrão Proxy

Twemproxy, ou nutcracker, é um exemplo histórico de proxy para Redis e Memcached. Ele reduzia conexões no backend, suportava sharding e expunha stats por porta de monitoramento. O trade-off é que o proxy vira parte crítica do data plane.

Use proxy quando:

• linguagens de cliente são inconsistentes,
• número de conexões é alto,
• mudança de topologia precisa ser centralizada,
• roteamento multi-pool é responsabilidade da plataforma.

Prefira roteamento no cliente quando:

• budget de latência é apertado,
• clientes são padronizados,
• suporte a Redis Cluster é maduro,
• proxy viraria gargalo.

Falhas de Roteamento

Hash Slots no Redis Cluster

Redis Cluster divide keyspace em 16.384 hash slots. Cada master possui um subconjunto de slots. Clientes normalmente roteiam direto para o nó dono do slot. Redis Cluster pode redirecionar clientes com MOVED e ASK.

Fórmula de Slot

HASH_SLOT = CRC16(key) mod 16384

Hash tags permitem colocar chaves relacionadas no mesmo slot.

user:{123}:profile
user:{123}:settings
user:{123}:permissions

Só o trecho dentro de {...} entra no hash de slot.

Topologia Redis Cluster

Implicações do Redis Cluster

1. Operações multi-key funcionam bem só quando chaves compartilham slot.
2. Hash tags ajudam, mas podem criar hot slots.
3. Clientes devem cachear slot map.
4. Clientes devem lidar com MOVED e ASK.
5. Redis Cluster usa replicação assíncrona.
6. Writes confirmados podem ser perdidos em janelas de falha.
7. Partições minoritárias param de aceitar writes após timeout.
8. Redis Cluster não faz proxy de comandos entre nós em operação normal.

Alerta Sobre Hash Tags

Hash tag resolve localidade. Também pode concentrar tráfego. Ruim:

tenant:{tenant_42}:all_products
tenant:{tenant_42}:all_orders
tenant:{tenant_42}:all_users

Melhor:

tenant:tenant_42:product:{product_123}
tenant:tenant_42:order:{order_900}
tenant:tenant_42:user:{user_77}

Use hash tag para operação multi-key atômica. Não use como hábito de namespace.

Memcached em Escala

Memcached é propositalmente simples. Clientes conhecem lista de servidores. Clientes fazem hash da chave para escolher servidor. Servidores não coordenam entre si. Essa simplicidade é o produto.

Modelo Memcached

Objetos Memcached incluem:

• chave,
• flags,
• tempo de expiração,
• bytes crus.

O servidor não entende JSON, Protobuf, schema de domínio ou relação entre objetos.

Por Que Times Ainda Usam Memcached

1. Operações simples e previsíveis.
2. Latência baixa para valores pequenos.
3. Escala horizontal de memória direta.
4. Bibliotecas maduras.
5. Sem expectativa oculta de persistência.
6. Ótimo para cache-aside de objetos simples.

Lições do Memcache no Facebook

O paper da Facebook na NSDI continua útil porque trata memcache como sistema distribuído construído de peças simples. Lições importantes:

• clientes e roteadores importam tanto quanto servidores,
• pools regionais reduzem latência,
• invalidação fica mais importante conforme escala cresce,
• leases ajudam contra stale sets e thundering herd,
• tooling operacional faz parte do design.

Slabs no Memcached

Memcached usa slab classes para alocação de memória. Itens de tamanho parecido compartilham classes. Isso melhora velocidade de alocação, mas desperdiça memória quando tamanhos não encaixam bem.

Eviction no Memcached

Memcached é LRU-style por padrão. Um item pode ser evictado antes do TTL se a slab class dele ficar sem chunks livres. TTL não garante sobrevivência. TTL é tempo máximo de vida, não mínimo.

Melhor Encaixe do Memcached

Use Memcached quando:

• valores são blobs serializados simples,
• não precisa de estrutura server-side,
• perder cache é aceitável,
• sharding no cliente é aceitável,
• replicação não é requisito,
• simplicidade operacional importa.

Use Redis quando:

• scripts ou funções atômicas são úteis,
• estruturas ricas ajudam,
• replicação e failover são necessários,
• sorted sets, counters ou streams ajudam,
• topologia nativa de cluster é desejada.

Replicação e Failover

Replicação melhora disponibilidade. Não transforma cache em banco.

Replicação no Redis

Redis normalmente usa primary-replica. Redis Cluster usa replicação assíncrona entre masters e replicas. Replicação assíncrona significa que primary pode confirmar write antes da réplica receber. Se primary falhar nessa janela, write pode ser perdido. Para cache, isso costuma ser aceitável. Para fonte de verdade, não.

Leituras de Réplica

Ler de réplica aumenta throughput. Também pode retornar valor antigo. Use para:

• views tolerantes a stale,
• leituras quase analíticas,
• dados derivados idempotentes,
• fan-out grande com freshness relaxado.

Evite para:

• alterações de permissão,
• decisões de segurança,
• configurações recém-alteradas,
• fluxos que exigem read-your-writes.

Matriz de Failover

Cache Multi-Região

Caches multi-região normalmente são regionais, não globalmente síncronos. Cache deve ficar perto da aplicação. Ler cache em outra região geralmente destrói o ganho de latência.

Padrão Regional

Estratégias Multi-Região

Budget de Freshness

Defina frescor em segundos. Não diga apenas "eventual". Exemplo:

Página de catálogo:
- TTL regional: 900 segundos
- lag p99 de invalidação: 10 segundos
- stale aceitável: 30 segundos
- alerta se lag > 60 segundos

Risco Multi-Região

O maior risco é staleness invisível. Cada região pode ter hit rate alto servindo valor antigo. Monitore versão de fonte, lag de evento e idade do objeto.

Invalidação e Estratégia de TTL

Só existem três ferramentas amplas de invalidação:

• deletar,
• sobrescrever,
• esperar expirar.

Sistemas de produção combinam as três.

Fluxo de Invalidação

Regras de TTL

1. TTL limita vida stale.
2. TTL não garante sobrevivência.
3. TTL deve ter jitter.
4. TTL muda por classe de objeto.
5. TTL deve ser curto para dado sensível.
6. TTL pode ser longo para dado estável e caro.
7. TTL não deve ser única invalidação para dado muito mutável.

TTL com Jitter

function jitterTtl(baseSeconds: number, jitterRatio: number): number {
  const spread = baseSeconds * jitterRatio;
  const min = baseSeconds - spread;
  const max = baseSeconds + spread;
  return Math.floor(min + Math.random() * (max - min));
}

Jitter evita expiração simultânea de muitas chaves.

Chaves Versionadas

Chaves versionadas evitam delete massivo.

catalog:v4:product:123
catalog:v5:product:123

Deploy de v5 abandona v4 naturalmente. Chaves antigas expiram depois. Esse padrão é ótimo para mudança de schema. Não resolve mudança de dado sozinho, a menos que versão de dado entre na chave.

Granularidade de Invalidação

Evite Scans Globais

Não dependa de KEYS product:* em produção. No Redis, SCAN serve para manutenção cuidadosa, não para invalidação no request path. Opções melhores:

• manter índice reverso por família,
• publicar chaves exatas de invalidação,
• usar namespaces versionados,
• deixar TTL limpar versões antigas,
• desenhar chaves sem fanout desconhecido.

Eviction e Gestão de Memória

Eviction não é detalhe de background. É o cache escolhendo quais objetos perdem.

Políticas de Eviction no Redis

Redis usa maxmemory-policy para decidir eviction. Políticas comuns:

• noeviction,
• allkeys-lru,
• allkeys-lfu,
• allkeys-random,
• volatile-lru,
• volatile-lfu,
• volatile-random,
• volatile-ttl.

Políticas volatile-* só removem chaves com TTL. Se não houver chave elegível, o comportamento pode ficar parecido com noeviction.

Escolha de Eviction no Redis

LRU Aproximado no Redis

LRU do Redis é aproximado. Ele amostra chaves em vez de manter lista global perfeita. Isso economiza memória e CPU. Também torna eviction probabilística. Só ajuste depois de medir.

Memória Fora do Eviction

Buffers de replicação e persistência no Redis podem consumir memória fora do dataset comparado com maxmemory. Deixe headroom. Não configure maxmemory igual à RAM total da máquina.

Memória no Memcached

Memcached aloca memória em slab classes. Uma classe pode evictar enquanto outra tem memória livre. Isso surpreende quem observa só memória global. Monitore evictions por slab.

Fragmentação

Fragmentação faz used_memory e RSS divergirem. Causas comuns:

• tamanhos variados de objetos,
• churn frequente,
• comportamento do allocator,
• valores grandes,
• buffers de persistência,
• output buffers de cliente,
• backlog de replicação.

Resposta operacional:

• limite tamanho de valor,
• separe workloads por tamanho,
• reinicie nós gradualmente quando necessário,
• ajuste allocator e active defrag quando disponível,
• mantenha headroom de memória,
• monitore fragmentation ratio.

Política de Tamanho de Objeto

Política recomendada:
- rejeitar valores acima de 1 MB por padrão
- avisar acima de 128 KB
- comprimir acima de 8 KB só depois de medir
- isolar cache de objetos grandes do cache de objetos pequenos e quentes

Valores grandes reduzem densidade efetiva do cache. Também aumentam latência de rede e risco de cauda.

Semântica de Consistência

Consistência de cache é decisão de produto expressa em infraestrutura.

Semânticas Comuns

Padrão Read-Your-Writes

Double Delete

Alguns sistemas deletam antes e depois do write no banco. Isso pode reduzir race de repopulação stale. Não prova correção. Também adiciona pressupostos temporais. Prefira outbox durável e checks de versão para caminhos críticos.

Risco de Cache Como Fonte de Verdade

Usar cache como banco começa silenciosamente:

• TTL desligado,
• writes só no Redis,
• recovery depende de RDB/AOF,
• sem histórico de auditoria,
• sem estratégia de migração,
• sem constraints relacionais,
• sem drill de restore,
• sem ownership de schema.

Redis pode ter persistência. Isso não transforma automaticamente um deploy de cache em banco durável. Durabilidade exige garantias de write, RPO/RTO, backup validado, ownership operacional e modelagem adequada.

Mitigação de Hot Keys

Hot key é uma chave cujo tráfego passa da capacidade confortável de um shard. É comum. Exemplos:

• configuração da homepage,
• perfil de celebridade,
• produto viral,
• feature flag global,
• plano de tenant gigante,
• chave inexistente atacada por bots.

Técnicas de Mitigação

Replicação de Hot Key

function hotReplicaKey(baseKey: string, replicas: number): string {
  const replica = Math.floor(Math.random() * replicas);
  return `${baseKey}:replica:${replica}`;
}

Em leitura, escolha réplica aleatória. Em write ou invalidação, atualize ou delete todas. Funciona para valores read-heavy quase imutáveis. É ruim para valor que muda muito.

Cache L1 Local

Use TTLs minúsculos no L1. Exemplos:

• 1 segundo para configuração muito quente,
• 5 segundos para fragmentos públicos de produto,
• 10-30 segundos para dicionários estáveis.

L1 pode multiplicar stale por milhares de processos. Use com escopo estreito.

Thundering Herd e Prevenção de Dogpile

Thundering herd acontece quando muitos requests dão miss juntos e batem na origem. Dogpile acontece quando uma chave quente expira e muitos requests recarregam ao mesmo tempo.

Request Coalescing

Coalescing em Processo

const inFlight = new Map<string, Promise<unknown>>();
async function coalesced<T>(key: string, loader: () => Promise<T>): Promise<T> {
  const existing = inFlight.get(key) as Promise<T> | undefined;
  if (existing) return existing;
  const promise = loader().finally(() => {
    inFlight.delete(key);
  });
  inFlight.set(key, promise);
  return promise;
}

Coalescing local ajuda dentro de uma instância. Locks distribuídos ou leases ajudam entre instâncias.

Padrão Lease

O paper de memcache do Facebook descreve leases para controlar stale sets e reduzir stampedes. Ideia geral:

• cache miss retorna lease token para um cliente,
• cliente com lease pode preencher,
• outros clientes esperam, servem stale ou tentam de novo,
• stale writes sem lease atual são rejeitados.

Soft TTL e Hard TTL

soft TTL: momento em que refresh deve começar
hard TTL: momento em que valor não pode mais ser servido

Kit Prático Contra Dogpile

1. Adicione jitter no TTL.
2. Use request coalescing.
3. Use stale-while-revalidate.
4. Use leases para hot keys.
5. Rate-limit no caminho de miss.
6. Aqueça chaves críticas antes de deploy.
7. Use L1 curto para hot keys extremas.
8. Sirva stale em erro da origem quando política permitir.

Negative Caching e Admission Control

Negative caching armazena misses. Exemplo:

negative:v1:product:missing_123 => "not_found" EX 30

Isso protege o banco contra consultas repetidas por objetos inexistentes.

Usos de Negative Cache

• produtos deletados,
• usernames desconhecidos,
• invite codes inválidos,
• feature flags inexistentes,
• IDs atacados por bots,
• checks de permissão com TTL muito curto.

Riscos de Negative Cache

Se TTL for longo, objetos recém-criados podem parecer ausentes. Se invalidação faltar, creates podem não aparecer. Se keyspace for atacável, atacante pode preencher memória com chaves negativas.

Admission Control

Não cacheie tudo. Admission control decide se valor merece memória.

Regras de Admission

1. Rejeite valores acima do tamanho máximo.
2. Rejeite respostas privadas one-off.
3. Rejeite resultados de baixa reutilização.
4. Rejeite dados sem invalidação clara.
5. Rejeite decisões sensíveis sem versionamento.
6. Prefira objetos canônicos a combinações arbitrárias de query.
7. Prefira leituras caras a leituras baratas.

Confiabilidade e Degradação

Falha de cache deveria degradar performance, não correção. Essa frase é fácil. Ela exige engenharia explícita.

Budget de Timeout

Meta p99 da API: 150ms
Budget de lógica do serviço: 40ms
Budget de fallback no banco: 80ms
Budget de cache get: 3ms
Budget de cache set: fire-and-forget ou 5ms no máximo

Nunca deixe chamada de cache consumir o budget inteiro do fallback.

Fluxo de Degradação

Circuit Breakers

Use circuit breakers ao redor de:

• cluster de cache,
• pool de proxy,
• workers de invalidação,
• loader da origem,
• serialização.

Estados:

• closed: normal,
• open: fail fast,
• half-open: testar recuperação.

Modos de Falha Seguros

Segurança

Caches frequentemente guardam dados derivados sensíveis. Trate-os como stores de produção em segurança, mesmo sem serem fonte de verdade.

Regras

1. Use rede privada.
2. Use TLS quando threat model pedir.
3. Use autenticação e ACLs.
4. Bloqueie comandos perigosos para usuários de aplicação.
5. Separe tenants em chaves e fisicamente quando necessário.
6. Não coloque secrets nas chaves.
7. Criptografe payload sensível na aplicação quando necessário.
8. Aplique retenção por TTL e deleção.
9. Evite cachear PII crua sem necessidade clara.
10. Inclua cache em incident response e deleção de dados.

Observabilidade e SLOs

Hit rate é útil. Hit rate não basta. Cache com 99% de hit rate pode estar quebrado se 1% de misses derruba o banco.

Golden Signals

Monitore por namespace, classe de objeto, região e tier de tenant:

• latência de get,
• latência de set,
• taxa de erro,
• taxa de timeout,
• hit rate,
• miss rate,
• carga de origem causada por miss,
• evictions,
• expirations,
• uso de memória,
• fragmentação,
• bytes de rede,
• conexões,
• amostras de hot key,
• lag de invalidação,
• stale serve count,
• contenção de lock,
• erro de serialização.

Exemplos de SLO

Dicas de Entrevista

Fluxo Forte

1. Clarifique quais dados são cacheáveis.
2. Diga que cache não é fonte de verdade.
3. Estime read QPS, miss QPS, memória e rede.
4. Comece com cache-aside.
5. Adicione TTL e invalidação explícita.
6. Adicione sharding com consistent hashing ou Redis Cluster.
7. Discuta replicação e failover sem exagerar garantias.
8. Trate hot keys e dogpile.
9. Adicione observabilidade.
10. Feche com trade-offs e anti-patterns.

Anti-Patterns

1. Cache Como Único Banco

Persistência do Redis não é plataforma de dados completa por si só. Se dado importa, desenhe durabilidade explicitamente.

2. Um TTL Global

Objetos diferentes têm freshness diferente. TTL único fica stale demais para dado sensível ou curto demais para dado estável.

3. Sem Jitter

Expirações alinhadas criam stampede previsível. Use jitter.

4. Cachear Tudo

Chaves de baixo reuso desperdiçam memória. Respostas grandes one-off expulsam objetos úteis.

5. Ignorar Tamanho de Objeto

Hit rate pode parecer bom enquanto byte hit rate é ruim. Meça ambos.

6. Usar KEYS em Produção

Scan global pode bloquear ou sobrecarregar Redis. Desenhe invalidação sem scan no request path.

7. Sem Timeout de Cache

Cache não pode consumir todo budget de latência da API. Use timeout curto e fallback.

8. Sem Proteção de Miss

Miss path precisa de coalescing, rate limit ou backpressure em escala.

9. Hash Tags em Tudo

Hash tags no Redis forçam localidade. Também podem criar hot slots.

10. Um Pool Para Tudo

Valores grandes e frios podem expulsar valores pequenos e quentes. Use isolamento de pool.

11. Hit Rate Como Único KPI

Hit rate sem carga na origem, frescor e latência é incompleto.

12. Cachear Autorização Por Muito Tempo

Permissão stale é bug de segurança. Use TTL curto, versão ou leitura direta da fonte.

Conclusão

Cache distribuído é sistema de controle de latência e carga. Redis e Memcached são escolhas de implementação dentro desse sistema. A verdade durável continua em outro lugar. O design de produção mora nas bordas:

• modelagem de chaves,
• política de TTL,
• invalidação,
• sharding,
• failover,
• hot keys,
• prevenção de dogpile,
• segurança,
• observabilidade,
• proteção do miss path.

Se você explica esses trade-offs, consegue desenhar um cache que aguenta tráfego real. Não apenas um cache que melhora benchmark.

Referências

• Redis Cluster specification
• Redis key eviction documentation
• Memcached documentation
• Memcached server maintenance documentation
• Memcached performance and efficiency documentation
• Memcached protocols documentation
• Scaling Memcache at Facebook, NSDI 2013
• Twemproxy / nutcracker

Referência Rápida

Seleção de Padrão

Redis vs Memcached

Regras Críticas

1. Banco guarda verdade.
2. Cache guarda velocidade.
3. TTL é vida máxima, não prova de correção.
4. Eviction pode acontecer antes do TTL.
5. Hot keys quebram sharding uniforme.
6. Miss QPS importa mais que hit rate médio.
7. Falha de cache não pode corromper dado.
8. Invalidação precisa de dono e métrica.
9. Valor grande precisa de admission explícito.
10. Segurança também vale para cache.

Compressão de Entrevista em 10 Minutos

Eu desenharia um cache distribuído cache-aside na frente do banco fonte.
Serviços usam biblioteca comum para chave, TTL, serialização, coalescing e métricas.
Redis Cluster ou Memcached shardado no cliente entrega escala horizontal.
Chaves incluem namespace, versão de schema, tenant, entidade, id e variante.
Writes fazem commit no banco primeiro e publicam evento de invalidação via outbox.
TTL com jitter limita stale e evita expiração sincronizada.
Miss path usa request coalescing, stale-while-revalidate, negative caching e admission control.
Hot keys são detectadas por amostragem e tratadas com L1, replicação, split ou isolamento.
Confiabilidade usa timeouts curtos, circuit breakers, fallback na origem e stale controlado.
Observabilidade mede latência, hit rate, miss QPS, evictions, memória, fragmentação, hot keys e lag.
Cache nunca é fonte de verdade sem redesenhar durabilidade, backup e consistência.