Sistema de notificações

01 · CONTEXTO

O que uma plataforma de notificações precisa fazer

Uma plataforma de notificações recebe de outros serviços uma mensagem e um destinatário e cuida da entrega por push, e-mail ou SMS. Além de enviar, ela precisa respeitar o que o usuário quer receber: a preferência de canal (opt-out) e os horários de silêncio fazem parte do problema, não são um enfeite. Em entrevista, o primeiro passo é levantar requisitos: quais canais, envio imediato ou agendado, envio individual ou em campanha para um segmento, e o que fica fora do escopo.

O desafio real não é a média, e sim o pico. Uma campanha que precisa chegar a muita gente em poucos minutos exige uma vazão muito acima da média do dia: a fonte do caso calcula que entregar um milhão em cinco minutos já passa de três mil por segundo, e propõe dimensionar o sistema para surtos de cinco mil por segundo. Esse descompasso entre média e pico é o que justifica colocar filas no meio do caminho.

02 · ARQUITETURA

Filas por canal e trabalhadores

O desenho básico separa quem pede a notificação de quem a entrega. O serviço de notificações valida o pedido, consulta as preferências do usuário e coloca um evento em uma fila de mensagens. Trabalhadores puxam os eventos da fila e os enviam ao serviço externo correspondente (push, SMS ou e-mail). A fila funciona como amortecedor quando o volume de notificações é alto, e por isso o pico não derruba a entrega.

Usar uma fila por canal é uma escolha de isolamento: se o provedor de SMS ficar lento, só a fila de SMS acumula, e o push e o e-mail continuam fluindo. Cada canal também escala seus trabalhadores de forma independente, já que cada provedor tem seu próprio ritmo e seus próprios limites.

1. Um serviço de origem pede o envio ao serviço de notificações; ele é a porta de entrada única da plataforma.

2. Antes de enfileirar, o serviço consulta as preferências: um canal em opt-out ou um horário de silêncio faz o pedido ser descartado ou adiado.

3. O evento vai para a fila do seu canal. As filas absorvem o pico e isolam um canal dos outros.

4. Trabalhadores de cada canal puxam os eventos da sua fila no ritmo que o provedor suporta.

5. Os trabalhadores chamam os provedores externos, que fazem a entrega final ao dispositivo, número ou caixa de e-mail do usuário.

03 · CONFIABILIDADE

Retentativas, fila de falhas e duplicatas

Provedores externos falham, e a plataforma precisa tentar de novo em vez de perder a notificação. Mensagens que esgotam as tentativas vão para uma fila de mensagens mortas (DLQ), e a documentação da Amazon SQS descreve a utilidade dela: isolar as mensagens não consumidas para investigar por que o processamento falhou. Assim a falha vira dado observável, e a mensagem pode ser reexaminada depois, em vez de sumir.

Retentativas têm um efeito colateral: a duplicata. A própria documentação da SQS avisa que filas padrão garantem entrega ao menos uma vez, e que mais de uma cópia da mensagem pode ser entregue. Por isso a entrevista pergunta como evitar duplicatas sobre uma entrega ao menos uma vez. A resposta prática é a idempotência: cada notificação carrega um identificador de evento, e o trabalhador confere se aquele identificador já foi processado antes de enviar.

1. O trabalhador recebe o evento da fila do canal.

2. Antes de enviar, ele confere o identificador do evento no registro de eventos já tratados; se já consta, a notificação não é reenviada.

3. O provedor externo fica indisponível: a chamada do trabalhador falha e a notificação ainda não foi entregue.

4. O evento volta a ser entregue pela fila e o trabalhador tenta de novo; é aqui que a checagem de duplicata importa.

5. Esgotadas as tentativas, o evento vai para a fila de mensagens mortas, onde pode ser investigado, e o monitoramento é avisado.

04 · PRIORIDADE E LIMITES

Prioridade, frequência e pontos únicos de falha

Nem toda notificação vale o mesmo. Um código de verificação não pode esperar atrás de uma campanha de marketing. A fonte do caso coloca isso como pergunta de aprofundamento: como entregar notificações de alta prioridade em poucos segundos mesmo durante uma campanha em massa. Uma saída coerente com o desenho é separar a fila de alta prioridade da fila de campanha, para que o volume de uma não bloqueie a outra.

Dois cuidados completam o desenho. O primeiro é limitar a frequência de notificações enviadas a cada usuário, para que ele não seja inundado; o mesmo raciocínio de um limitador de taxa vale aqui. O segundo é evitar pontos únicos de falha: as notas de estudo alertam que um único servidor de notificações pode derrubar o sistema inteiro, e por isso o serviço de entrada precisa de várias instâncias atrás de um balanceador de carga.

05 · DISPONIBILIDADE

Não perder o que foi aceito

A fonte do caso destaca uma pergunta que resume a promessa do sistema: como garantir que uma notificação aceita nunca seja descartada. A resposta passa por gravar o pedido de forma durável antes de confirmar ao chamador, e só tratar a entrega como concluída quando o provedor responder. Isso conecta o caso a padrões de disponibilidade: redundância no serviço de entrada, filas replicadas e trabalhadores sem estado que podem ser substituídos.