Na terça-feira, 10 de novembro, aconteceram duas coisas que parecem notícias separadas e que, na minha opinião, são a mesma história. O .NET 8 e o .NET 9 saíram de suporte. E a Microsoft publicou, no mesmo dia, o Patch Tuesday mais volumoso que eu já vi: algo perto de 1.100 correções de segurança, dependendo de quem faz a contagem. O que aconteceu O calendário já estava anunciado desde junho. Em 10 de novembro de 2026, .NET 8 (LTS) e .NET 9 (STS) deixaram de receber correções de segurança e suporte técnico. O .NET 9 acabou junto com o 8 porque o ciclo de suporte das versões STS foi esticado de 18 para 24 meses, e a conta fechou na mesma data. A recomendação oficial é migrar para o .NET 10, que é LTS e tem suporte até novembro de 2028. A aplicação continua rodando, ninguém vai desligar nada, mas o que for descoberto daqui para frente não será corrigido para essas versões. Já o Patch Tuesday trouxe, segundo o Krebs on Security, 1.093 vulnerabilidades corrigidas, com 63 críticas e u...
Todo mundo que já colocou uma API em produção conhece o filme: o endpoint de leitura é simples, mas a consulta por trás dele é cara, e a mesma linha é pedida centenas de vezes por minuto. Aí alguém sugere "põe um Redis na frente". Funciona, mas o difícil não é gravar no cache, é decidir quando ler, quando invalidar e o que fazer quando dez requisições chegam juntas e o cache está vazio. Neste post eu montei um exemplo pequeno com FastAPI e Redis usando o padrão cache-aside, e dei atenção a esses dois pontos chatos: invalidação e requisições simultâneas. Tudo roda com docker compose e os testes não precisam de um Redis de verdade. A ideia: cache-aside No cache-aside quem manda é a aplicação, não o cache. O fluxo de leitura é sempre o mesmo: pergunta ao Redis; se tem, devolve; se não tem, busca na fonte de verdade, grava no Redis com um TTL e devolve. Na escrita, a gente muda a fonte e apaga a chave do cache, deixando a próxima leitura repovoar. É menos esperto que write-...