Design de Sistema de Notificações

O problema

Notificação parece um problema simples até você listar o que realmente entra nessa palavra.

Ela pode significar:

• push
• e-mail
• SMS
• mensagem dentro do produto

E cada canal tem:

• custo diferente
• latência diferente
• provider diferente
• política diferente

Se você tratar tudo como “manda uma mensagem”, a resposta fica rasa e o sistema fica ruim.

Modelo mental

O jeito mais útil de pensar em notificações é separar três partes:

1. trigger
2. roteamento
3. entrega

O trigger responde: qual evento gerou a notificação?

O roteamento responde: esse usuário deve receber isso por qual canal, com qual prioridade e em qual momento?

A entrega responde: como falar com APNs, FCM, provider de e-mail, SMS ou canal interno?

Essa separação ajuda porque cada etapa falha de um jeito diferente.

Quebrando o problema

Nem toda notificação merece o mesmo tratamento

Compare estes casos:

• alerta de segurança
• confirmação de compra
• campanha promocional

Uma não pode atrasar muito. Outra pode atrasar um pouco. Outra talvez nem devesse ser enviada se o usuário já demonstrou desinteresse.

Então a arquitetura precisa reconhecer categoria e prioridade cedo.

Sem isso, o sistema trata mensagem promocional e evento crítico com o mesmo nível de urgência.

O fluxo principal não deveria esperar entrega

Se uma compra foi concluída, o pedido não deveria falhar só porque o provider de e-mail está lento.

Por isso, o desenho normal é:

1. o evento principal acontece
2. a intenção de notificar entra em fila
3. workers processam depois

Esse desacoplamento é uma das partes mais importantes da resposta.

Roteamento por canal e preferência

Antes de entregar, o sistema precisa decidir:

• qual canal usar
• se o usuário autorizou esse canal
• se aquela categoria está liberada
• se vale tentar mais de um canal

Opt-out não é detalhe de interface. É regra central do sistema.

Retry, idempotência e deduplicação

Sistema de notificação trabalha muito com tentativa repetida.

Pode haver:

• timeout
• provider instável
• resposta ambígua
• reprocessamento de fila

Então o sistema precisa aceitar retry sem transformar isso em spam ou duplicidade visível.

Em muitos casos, entregar uma vez a menos é melhor do que entregar três vezes a mais.

Rate limiting e proteção contra excesso

Mesmo quando a entrega funciona, o sistema ainda pode ser ruim para o usuário.

Arquitetura madura normalmente inclui regras como:

• no máximo X push por período

• consolidar eventos parecidos

• separar fila crítica de fila promocional

• respeitar janela de silêncio ou preferência de horário quando fizer sentido

Esse ponto costuma diferenciar resposta de produto real de resposta escolar.

Exemplo simples

Uma resposta boa em entrevista poderia soar assim:

“Eu trataria notificação como sistema assíncrono. O evento principal gera uma intenção de notificar e isso entra em fila, sem bloquear o fluxo original. Depois, um roteador decide canal, prioridade e horário com base no tipo da mensagem e nas preferências do usuário. A entrega fica separada por canal, porque push, e-mail e SMS falham de jeitos diferentes. Também colocaria idempotência e deduplicação para lidar com retry, além de rate limiting por usuário para evitar spam.”

Essa resposta funciona porque ela:

• desacopla o fluxo principal
• reconhece canais diferentes
• trata prioridade e preferência como arquitetura
• mostra maturidade sobre retry

Erros comuns

• Fazer o fluxo principal depender da entrega do canal.
• Tratar todos os canais como se fossem iguais.
• Misturar alerta crítico com marketing na mesma fila.
• Ignorar opt-out e preferência do usuário.
• Pensar só em “entregar” e esquecer excesso e ruído.

Como um senior pensa

Quem tem experiência com esse tipo de sistema normalmente faz duas perguntas cedo:

Essa mensagem pode ser perdida?

Essa mensagem pode virar ruído se eu mandar demais?

Essas duas perguntas já organizam prioridade, canal, retry e rate limiting quase sozinhos.

O que o entrevistador quer ver

Nesse cenário, o entrevistador quer ver se você:

• separa trigger, roteamento e entrega
• entende por que o sistema costuma ser assíncrono
• lembra de retry, idempotência e deduplicação
• trata prioridade e preferência como parte do design
• evita resposta simplista do tipo “uso uma fila e pronto”

Notificação boa não é só a que entrega. É a que entrega a mensagem certa, no canal certo, sem travar o produto nem cansar o usuário.

Quando você separa intenção, decisão e entrega, o sistema para de parecer um balde único de mensagens.