Cache Aside vs Read behind vs Write through vs Read though

Fala pessoal, tudo certo? 👋

Hoje a pauta é simples, mas nem por isso fácil: qual estratégia de cache faz sentido pro seu sistema?

A gente adora jogar um Redis ali no meio da stack e achar que resolveu todos os problemas de performance da aplicação. Mas… cache mal usado mais atrapalha do que ajuda. E sim — é aquele tipo de solução que funciona bem… até parar de funcionar. (- Quem nunca falou de usar in-memory db só pra melhorar latência durante uma entrevista ?! ahahha)

Uma vez, me chamaram pra ver um sistema que “tava voando com cache”.(voando pro buraco, isso sim). Era dado desatualizado, comportamento estranho, e ninguém sabia quem atualizava o quê. O clássico: botei cache para melhorar latência e agora o problema não é lentidão e sim inconsistência de dados.

E é aí que a coisa desanda. Cache não é só performance — é decisão arquitetural. Por isso insisto tanto na CaD: esse é o tipo de coisa que Senior de verdade, Especialista ou Staff precisa dominar pra guiar a empresa na direção certa e evitar aquela “enchadada que só traz minhoca”.

Então, vamos nessa, deixa te explicar 4 estratégias de utilizar cache de dados.

1️⃣ Cache Aside (o “tô no controle”… ou pelo menos acho que tô)

É o modelo mais manual. A aplicação faz tudo:

1. Primeiro, tenta buscar o dado no cache.
2. Se encontrar, beleza, já responde.
3. Se não encontrar, busca no banco de dados,
4. Armazena esse resultado no cache,
5. E só então responde pro usuário.

Ou seja: quem decide o que vai pro cache, quando vai e por quanto tempo… é você (ou o dev que escreveu isso 2 anos atrás).

🔎 Vale quando:

• Você quer controle total sobre o cache e consegue gerenciar TTLs e invalidações.
• As leituras são bem mais frequentes que as escritas.
• Cada aplicação pode seguir sua própria lógica sem depender de um ponto central.

⚠️ Cuidado:

• TTL infinito? Vai entregar dado velho sem perceber.
• Esqueceu de invalidar o cache depois de uma escrita? Vai dar inconsistência.
• Em sistemas distribuídos, cada aplicação precisa implementar essa lógica — se cada uma fizer diferente, já sabe o resultado.

2️⃣ Write Through (o “escreveu, já tá quente”)

Aqui o fluxo acontece no momento da escrita, não da leitura:

1. A aplicação recebe a requisição para salvar ou atualizar um dado.
2. Em vez de só mandar pro banco, ela salva ao mesmo tempo no banco e no cache.
3. Pronto. A próxima leitura já encontra tudo no cache, bonitinho e atualizado.

Esse modelo garante que o cache nunca fique desatualizado. Mas… você tá escrevendo em dois lugares. Se um deles falhar, você precisa tratar.

🔎 Vale quando:

• Leitura precisa ser rápida e sempre atualizada.
• Você tolera um pequeno impacto na performance de escrita.
• O volume de escrita é controlado e você consegue garantir atomicidade entre cache e banco.

⚠️ Cuidado:

• Se o cache estiver fora do ar, sua escrita falha ou fica incompleta.
• Se der erro só em um dos lados (ex: banco foi, cache não), o dado pode ficar inconsistente.
• Sem bons mecanismos de retry/rollback, esse modelo vira armadilha.

3️⃣ Write Behind (o “deixa que depois eu salvo”)

Aqui é quase um “Write Through”, mas assíncrono. O fluxo muda assim:

1. A aplicação recebe a requisição de escrita,
2. Salva apenas no cache (ou numa fila, dependendo da implementação),
3. Retorna a resposta pro usuário rapidão,
4. E depois, um processo assíncrono grava esse dado no banco de dados.

Ou seja, o cache vira a fonte temporária da verdade, e a persistência acontece por trás dos panos.

🔎 Vale quando:

• Performance de escrita é crucial e você pode esperar um pouco pra persistir os dados.
• Seu sistema é tolerante à consistência eventual.
• Já tem algum job, worker ou fila confiável pra cuidar da gravação no banco.

⚠️ Cuidado:

• Cache é volátil. Se cair antes de gravar no banco, perdeu o dado.
• Dá pra mitigar com persistência em disco, logs de alteração ou buffers — mas aí começa a complicar.
• Você precisa garantir que o processo de flush pro banco esteja vivo, rápido e confiável.

4️⃣ Read Through (o “cache com cérebro”)

Aqui o cache deixa de ser só um atalho e vira parte do fluxo de leitura. O que muda:

1. A aplicação sempre consulta o cache.
2. Se o dado estiver lá, responde na hora.
3. Se não estiver, o próprio cache se encarrega de ir no banco,
4. Recupera o dado,
5. Armazena no cache,
6. E aí sim devolve pra aplicação.

A grande diferença pro Cache Aside é que a lógica de fallback pro banco está no cache, não na aplicação. Mais limpo e mais desacoplado.

🔎 Vale quando:

• Você quer simplificar o código da aplicação e centralizar a lógica de cache.
• Usa ferramentas que suportam esse modelo (ex: proxies, gateways, libs especializadas).
• Quer evitar que cada aplicação implemente sua própria lógica de “fallback”.

⚠️ Cuidado:

• Adiciona uma latência extra nas primeiras leituras (cache miss).
• Se o cache falhar, sua aplicação pode travar junto — já que depende dele pra buscar no banco.
• Centralizar é bom, mas também pode virar um single point of failure se não for bem arquitetado.

Conclusão

A real é que cache é um dos maiores causadores de bugs silenciosos que existem. O sistema parece rápido, os logs mostram 200ms de resposta, mas… tá servindo dado de dois dias atrás. E às vezes nem é só isso — cada serviço acessando o mesmo cache começa a enxergar versões diferentes da realidade. Aí já era: debug impossível, comportamento aleatório, e ninguém sabe mais o que é verdade.

Se você não sabe onde tá o centro da verdade, quem atualiza o quê e quando os dados vencem, então não tem cache. Tem uma bomba-relógio — e ela vai estourar na hora mais inconveniente possível.

É exatamente por isso que esse tipo de tema volta e meia aparece no CaD. Lá, a gente não fica só no conceito bonito pra postar no LinkedIn — a ideia é entender os porquês, fazer escolhas com critério e montar ambientes modernos, resilientes e de alta qualidade.

Se você quer se tornar um Senior ou especialista, tá na hora de jogar no modo avançado!

👉 https://mugnos-it.com/cad

Nos vemos no próximo!

Douglas Mugnos.