Caching

Um cache na frente do banco para dados muito lidos e pouco escritos, com a estratégia escolhida pelo que cada dado tolera: saldo em cache-aside com invalidação a cada escrita, limite do cartão em write-through, e write-behind só para um contador que pode ser recalculado. O cache acelera; se cair, tudo continua lendo do banco. Use quando leituras repetidas sobrecarregam o banco.

passos: 6
arquivos: 3
testes: 0
tecnologias: 5

Infraestrutura realTypeScriptBunPostgreSQLRedisDocker

Cenário Relações Comparar

Baixar cartão

Cenário

A home do app do banco mostra o saldo a cada abertura; no horário de pico, centenas de telas pedem o mesmo saldo ao mesmo tempo. Um PIX debitado não pode deixar o saldo antigo na tela por 30 segundos. O limite do cartão não pode estar desatualizado depois de uma alteração. A contagem de PIX do dia, usada em painéis, pode ser gravada em lote — se um lote se perder, ela é recalculada das transações.

Planta

Sequência

10/10

10 passos — reproduza para seguir o fluxo

chamada
resposta ou assíncrono
falha
passo
toque num participante para focar
Outras plantas de sequência

Como funciona

6 passos

Hit no cache, miss no banco.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

SET NX EX+2

DEL+1

Leader Election

01
Saldo em cache-asideNo miss, SET NX EX elege um único leitor para ir ao banco; os outros esperam o valor aparecer no Redis — sem stampede
02
Depois de todo débito o saldo em cache é apagado (DEL); o TTL de 30 s é só rede de segurança
03
Limite do cartão em write-throughBanco e cache atualizados na mesma operação, a leitura seguinte já vê o novo limite
04
Contagem de PIX em write-behindHINCRBY por PIX; o flush pega o hash com RENAME (atômico), grava em lote no PostgreSQL e o apaga — um flush interrompido é concluído pelo seguinte
05
Qualquer falha do Redis vira "sem cache": a leitura vai ao banco e o erro é só contado
06
stats mede acertos e idas ao banco; acerto abaixo de 80% indica TTL curto demais ou dado que não se beneficia do cache

Trade-offs

O que se ganha, o que se paga

Estratégia	Vantagem	Desvantagem
Cache-aside + invalidação	Simples, só o que é lido vai para o cache	Primeira leitura após invalidar vai ao banco
Write-through	Leitura nunca desatualizada após escrita	Toda escrita custa duas operações
Write-behind	Escrita barata, gravação em lote	Flush perdido perde dados: só para o que se recalcula

apps/scalability/caching

3 arquivos

src/

cache_account.tsAs três estratégias, o lock contra stampede e o flush do write-behind
repository_account.tsFonte da verdade no PostgreSQL, com contagem de leituras

sql/