EP6: Arquitetura Escalável de Notificações |SSE + Redis Routing
Notificações em Tempo Real com SSE + Redis Routing
🧭 Mapa da Edição
📓 Quando o fan-out vira caos: uma rota mais esperta com SSE e Redis
🌊 IA acelerando mais rápido que os trailers do GTA, novos modelos com nomes cada vez mais confusos, e tokens fluindo como água no OpenRouter.
📦 Do fundo do mar dev: automações que não encalham, uploads descomplicados e gráficos que navegam via query.
📓 Entrada no LogBook
Há alguns dias me deparei com um artigo bem interessante da galera da Trendyol sobre como eles usaram Server-Sent Events (SSE) pra entregar notificações em tempo real.
A sacada é boa — SSE é leve, confiável e resolve bem quando a comunicação é só do servidor pro cliente.
Mas teve um trecho que me fez parar pra pensar:
“Todas as instâncias da API se inscrevem no mesmo canal Redis e filtram os eventos em memória.”
Pensa comigo: num sistema grande, com muitos usuários e muitos eventos... esse fan-out vira um pesadelo.
Cada instância recebendo tudo, pra depois descartar 99%? 🤯
Isso me fez imaginar uma abordagem diferente. Algo mais inteligente. Algo que... não colocasse todas as instâncias pra ouvir o universo.
E se a gente invertesse a lógica?
Ao invés de sair disparando notificações pra todos os pods e pedir que eles filtrem localmente, pensei:
“Por que não perguntar pro Redis onde o usuário está... e mandar só pra lá?”
A ideia seria mais ou menos assim:
📅 Quando o usuário se conecta via SSE, o pod que o atende registra isso no Redis:
SET user-session:123 = 'read-api-B' EX 60
🔁 Quando chega uma notificação pra esse usuário, a service que dispara o evento pergunta:
const pod = await redis.get('user-session:123')
Se o Redis responde read-api-B, a mensagem vai direto pro canal daquele pod:
PUBLISH notification:read-api-B { userId: 123, message: 'Nova venda!' }
O pod já tá ouvindo esse canal. Recebe, valida, e empurra a notificação via SSE pro navegador do João.
Sem ruído. Sem sobrecarga. Sem caos.
Essa inversão de lógica parece resolver três dores de uma vez:
Reduz fan-out sem abrir mão do SSE
Ganha escalabilidade sem complicar a arquitetura
Mantém o controle fino sobre quem ouve o quê
Ainda estou digerindo e refletindo se isso se sustentaria bem num ambiente de produção grande, mas confesso que gostei da direção.
Quem sabe vale a pena um experimento?
E você, como lida com notificações em tempo real na sua stack?
Já teve dor de cabeça com Redis Pub/Sub ou SSE em produção?
🌊 Marés da semana
Google lançou (de novo) seu modelo de IA mais potente, o Gemini 2.5 Pro, uma versão melhorada no caso - Gemini 2.5 Pro Preview! Engraçado né, primeiro 2.5 Pro Experimentação, 2.5 Pro Flash Preview e agora… apenas Preview. Quem inventa esses nomes em?
OpenRouter anunciou um suporte a um novo provedor para modelos OpenSource na plataforma, o Cerebras. Praticamente um speedster com incriveis ~2k tokens por segundo! 🤯
E no mundo dos games, a lenda desperta novamente: Novo trailer do GTA VI foi lançado! Muita coisa aleatória, linda e curiosa, mas não vou mentir… pra mim deixou um gostinho de “que mais?”
📦 Treasure - Good Stuff
Aproveitando a onda de back-end, aqui vai um tesouro relacionado:
Trigger.dev - Absurdo pra fazer background jobs, inclusive AI Agents de um jeito bem simples sem depender de Crons ou qualquer trativa mais cabulosa que você esteja fazendo.
Sabia que da pra gerar gráficos via chamada API? Com Quickchart.io isso é possível, basta passar os dados via query params (cuidado aqui em) → Exemplo
Cansado das cobranças da AWS S3 ou precisa de novas opções? Curti bastante a Uploadthing pela facilidade e custo-benefício.