Case: sistema de notificações em escala
- ⬜💬 Case: chat / messaging (WhatsApp-like)(System Design Interview Prep)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Por que isto é mais difícil do que parece
"Mandar notificação" soa trivial até você contar os modos de falha. O sistema fala com serviços de terceiros que ficam fora do ar, precisa respeitar preferência de cada pessoa, não pode acordar ninguém às três da manhã, e jamais pode mandar a mesma coisa duas vezes — porque, ao contrário de um feed, notificação duplicada é visível e irrita.
Some a isso o volume: um evento no produto pode gerar milhões de notificações em segundos, e o serviço de push do fabricante tem limite de taxa que você não controla.
A pergunta que orienta o desenho inteiro
Notificação é entrega best-effort ou tem garantia? "Seu pedido saiu para entrega" e "curtiram sua foto" merecem tratamentos opostos: a primeira precisa chegar, a segunda pode ser descartada num pico. Se você não separar as duas, ou desperdiça infraestrutura ou perde o que importava.
O desenho, e por que ele tem tantas etapas
- → crítica
- → engajamento
- Integração de apps
- Banco de dados
- Conceito de arquitetura
- Gestão e governança
Repare quantas barreiras existem ANTES da fila: preferência, deduplicação e limite por pessoa. Todas evitam trabalho; nenhuma é entrega. Um sistema de notificação bem desenhado gasta a maior parte da lógica decidindo NÃO enviar.
- 1 · O evento não decide sozinho. Separar "aconteceu algo" de "avise fulano" é o que permite mudar a política de notificação sem tocar no serviço que gerou o evento.
- 2 · Preferência antes de qualquer trabalho. Consultar cedo evita gastar fila e chamada de terceiro com notificação que a pessoa desligou. Horário de silêncio entra aqui: em vez de descartar, costuma-se adiar para a manhã.
- 3 · Deduplicação é obrigatória, não refinamento. A fila entrega pelo menos uma vez, e uma repetição vira segunda notificação no aparelho de alguém. Uma chave do evento com expiração curta resolve — e é a diferença entre um sistema utilizável e um que as pessoas desativam.
- 4 · Limite por pessoa protege o produto. Um laço com defeito pode gerar mil notificações para o mesmo usuário. O teto por pessoa e por hora é o que transforma um incidente numa anomalia registrada, em vez de desinstalações.
- 5 · Duas filas, porque as garantias são diferentes. Sob pressão, dá para descartar engajamento e preservar transacional. Com fila única, ou você trata tudo como crítico e paga por isso, ou perde o que não podia perder.
- 6 · Rastrear é o que permite melhorar. Enviado não é entregue, e entregue não é aberto. Sem os quatro estados, não há como saber se o problema é o serviço do fabricante, o texto ou o horário.
O canal que se comporta diferente de todos
SMS custa por mensagem e o custo varia por país. É o único canal em que um defeito de laço vira fatura, e por isso costuma ter teto de gasto próprio, separado do limite por pessoa.
Por que um sistema de notificação precisa desacoplar produção e entrega?
O que fazer quando o terceiro está fora do ar
Você não controla o serviço de push do fabricante nem o provedor de e-mail. A diferença entre um sistema robusto e um frágil é o que acontece nesse minuto.
| Falha | Reação errada | Reação correta |
|---|---|---|
| Erro temporário (5xx, limite de taxa) | Repetir imediatamente, em laço | Repetir com espera crescente e um pouco de aleatoriedade — sem ela, todos os trabalhadores repetem no mesmo instante e derrubam o serviço de novo quando ele volta |
| Erro permanente (token inválido) | Repetir até esgotar as tentativas | Marcar o token como morto e parar. Aparelho desinstalado gera erro permanente, e insistir gasta cota pelo resto da vida |
| Provedor fora por horas | Acumular tudo e disparar de uma vez quando voltar | Fila de mensagens mortas com inspeção, e decisão explícita: notificação de engajamento de três horas atrás não interessa mais e deve ser descartada |
O erro de recuperação mais caro
Acumular seis horas de notificações e despejar todas quando o provedor volta produz um segundo incidente, agora do lado do usuário: dezenas de alertas de uma vez. Descartar o que envelheceu é parte do projeto, não perda de dado.
Perguntas frequentes
❓ Como projetar um sistema de notificação?
❓ Como evitar duplicata em notificação?
❓ Como lidar com pico de disparo?
Fixando
Como evitar enviar a mesma notificação duas vezes?
Qual é o requisito de produto frequentemente esquecido no projeto técnico?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…