Caching
IMemoryCache, IDistributedCache, HybridCache e estrategias de invalidacao no .NET
Principio: Cache e uma troca de consistencia por performance. Dados obsoletos sao aceitaveis? Por quanto tempo? Essas perguntas definem sua estrategia.
Cache-Aside Pattern
O padrao mais comum: a aplicacao verifica o cache primeiro. Em caso de miss, busca no banco, armazena no cache, e retorna. O cache nao conhece o banco — a aplicacao orquestra tudo.
| Tipo | Onde armazena | Escopo | Quando usar |
|---|---|---|---|
| In-Memory | Heap do processo | Por instancia da app | Dados pequenos, leitura frequente, uma unica instancia |
| Distributed | Redis, SQL Server, NCache | Compartilhado entre instancias | Multiplas instancias, dados maiores, persistencia alem do processo |
| HybridCache (.NET 9) | L1 in-memory + L2 distributed | Ambos | Melhor dos dois mundos — L1 para velocidade, L2 para consistencia |
| Response Cache | HTTP headers (CDN, browser) | Cliente/proxy | Conteudo estatico, APIs read-only com Cache-Control |
| Output Cache (.NET 7+) | Server-side, resposta inteira | Por instancia (ou distributed) | Endpoints identicos para muitos usuarios |
Estrategias de expiracao
| Tipo | Comportamento | Exemplo |
|---|---|---|
| Absolute | Expira em tempo fixo apos criacao | Categorias: 1 hora. Nao importa quantas vezes acessar. |
| Sliding | Expira se nao acessado por X tempo | Sessao de usuario: 20 min de inatividade. |
| Absolute + Sliding | Sliding renova ate o limite absoluto | Sliding 5 min, absoluto 30 min. Evita cache eterno. |
In-memory vs distributed cache — como escolher?
In-memory e mais rapido (nanossegundos, sem rede), mas cada instancia tem sua copia — inconsistencia entre pods. Distributed (Redis) garante uma unica fonte de verdade para todas as instancias, mas adiciona latencia de rede (~1ms). Para dados que mudam pouco e sao lidos milhares de vezes (categorias, config), in-memory e ideal. Para dados de sessao ou inventario compartilhado, distributed.