Projetando um Sistema Global de Notificações: Guia Completo de System Design

Resumo: Um guia de arquitetura em nível de produção para plataformas de notificação multicanal (push, email, SMS e in-app), cobrindo ingestão de eventos, preferências e consentimento, roteamento, templates, entrega, deduplicação, retries, confiabilidade e observabilidade.

Publicado: Fevereiro 2026 Tempo de leitura: 85 minutos Palavras-chave: #SystemDesign #NotificationSystem #Push #Email #SMS #InApp #SistemasDistribuídos #Escalabilidade #EntrevistaTécnica

Um usuário conclui um pedido. Em segundos, o sistema precisa enviar:

• push de confirmação,
• email com recibo,
• SMS apenas se for evento crítico,
• atualização no inbox in-app.

E precisa evitar:

• mensagens duplicadas,
• canal bloqueado por preferência,
• envio em horário silencioso,
• spam de baixa prioridade em momentos críticos.

Esse é o desafio real: enviar é fácil; enviar certo, no canal certo e no tempo certo, em escala global, é difícil.

Sumário

• Análise de Requisitos
• Cálculos de Envelope
• Arquitetura de Alto Nível
• Modelo de Domínio
• Contratos de API e Eventos
• Ingestão e Normalização (Core 1)
• Preferências, Consentimento e Quiet Hours (Core 2)
• Templates e Localização (Core 3)
• Roteamento e Seleção de Canal (Core 4)
• Fanout, Agendamento e Batching (Core 5)
• Pipelines por Provedor (Core 6)
• Deduplicação e Idempotência (Core 7)
• Retry, DLQ e Recuperação (Core 8)
• Caching e Storage
• Confiabilidade e Modos de Degradação
• Observabilidade e SLOs
• Dicas de Entrevista
• Anti-Patterns
• Conclusão
• Referências
• Referência Rápida

Análise de Requisitos

Requisitos Funcionais

1. Receber eventos de vários serviços.
2. Suportar push, email, SMS e in-app.
3. Respeitar preferência, consentimento e compliance.
4. Renderizar templates localizados.
5. Deduplicar eventos e envios.
6. Agendar por timezone e quiet hours.
7. Rastrear estado de entrega e engajamento.
8. Reprocessar falhas com retry e DLQ.
9. Oferecer controles operacionais para incidentes/campanhas.

Requisitos Não-Funcionais

Perguntas de Clarificação

1. Escopo inclui marketing ou só transacional?
2. Exactly-once é exigido ou effectively-once basta?
3. Precisamos ordenação de notificações?
4. Quais normas/regulações se aplicam?
5. Qual janela de retenção do histórico?

Premissas:

• transacional + marketing,
• comportamento effectively-once para o usuário,
• enforcement de preferência antes do envio,
• operação global timezone-aware.

Cálculos de Envelope

Escala Assumida

DAU: 300 milhões
Eventos/dia que disparam notificação: 15 bilhões
Fanout médio por evento: 1,4
Notificações/dia: 21 bilhões
Mix:
- Push 70%
- Email 20%
- SMS 5%
- In-app 5%
Pico: 6x

Throughput

Notificações/s média ~= 243.055
Pico ~= 1.458.330/s

Pressão por Canal no Pico

Push ~= 1.020.831/s
Email ~= 291.666/s
SMS ~= 72.916/s
In-app ~= 72.916/s

Storage Direcional

Com 450 bytes de metadata por notificação:

21B * 450B ~= 9,45TB/dia

Insight

A complexidade maior está em policy, dedupe e confiabilidade por canal, não na serialização da mensagem.

Arquitetura de Alto Nível

Princípios

1. Normalizar cedo.
2. Bloquear por preferência antes de fanout.
3. Isolar conectores por canal.
4. Dedupe e retry como pilares.

Modelo de Domínio

Entidades

1. NotificationRequest
2. NotificationMessage
3. DeliveryAttempt
4. PreferenceProfile
5. ConsentRecord
6. TemplateVersion
7. ProviderReceipt

Lifecycle

RECEIVED -> ELIGIBLE -> SCHEDULED -> DISPATCHED -> PROVIDER_ACCEPTED -> DELIVERED/FAILED

Distinção Essencial

• Request: intenção de negócio.
• Message: instância por canal.
• Attempt: tentativa de entrega no provider.

Contratos de API e Eventos

Ingest API

POST /v1/notifications/emit

{
  "event_id": "evt_441",
  "event_type": "ORDER_CONFIRMED",
  "tenant_id": "t_22",
  "user_id": "u_77",
  "priority": "HIGH",
  "payload": {
    "order_id": "ord_991",
    "amount": "129.99",
    "currency": "USD"
  },
  "idempotency_key": "3f9d63d6-8dd0-4a4e-96a2-5cf5ae5f9f12"
}

Evento de Entrega

{
  "notification_id": "n_991",
  "channel": "PUSH",
  "provider": "FCM",
  "attempt": 1,
  "state": "PROVIDER_ACCEPTED",
  "provider_message_id": "fcm_abc",
  "occurred_at": "2026-02-22T23:22:01Z"
}

Ingestão e Normalização (Core 1)

Etapas

1. validar schema e auth,
2. mapear evento para formato canônico,
3. enriquecer contexto,
4. anexar trace ids,
5. publicar intent normalizado.

Regras de Validação

• campos obrigatórios por evento,
• limite de payload,
• autorização por tenant,
• sanity checks de prioridade.

Preferências, Consentimento e Quiet Hours (Core 2)

Dimensões

1. opt-in/opt-out por canal,
2. preferência por tópico,
3. transacional vs marketing,
4. quiet hours por timezone,
5. consentimento regulatório.

Exemplo de Resultado

{
  "user_id": "u_77",
  "eligible_channels": ["PUSH", "IN_APP"],
  "suppressed_channels": [
    { "channel": "SMS", "reason": "NO_CONSENT" },
    { "channel": "EMAIL", "reason": "QUIET_HOURS" }
  ]
}

Regra

• transacional crítico pode furar quiet hour conforme policy.
• marketing sempre respeita quiet hour.

Compliance

Consentimento precisa histórico auditável (quem, quando, como).

Templates e Localização (Core 3)

Requisitos

1. versão de template,
2. fallback de locale,
3. render seguro,
4. formato por canal.

Exemplo

{
  "template_id": "order_confirmed_v5",
  "channel": "EMAIL",
  "locale": "pt-BR",
  "subject": "Seu pedido {{order_id}} foi confirmado",
  "body": "Oi {{first_name}}, total {{amount}} {{currency}}.",
  "version": 5,
  "status": "ACTIVE"
}

Render Rules

1. whitelist de variáveis,
2. fallback locale (pt-BR -> pt -> en-US),
3. validação antes de enviar.

Roteamento e Seleção de Canal (Core 4)

Inputs

1. prioridade do evento,
2. preferência/consentimento,
3. saúde do canal,
4. custo,
5. regra de negócio.

Exemplo de Policy

ORDER_CONFIRMED:
- primário: PUSH
- fallback: EMAIL
- SMS apenas para casos críticos

Objeto de Decisão

{
  "notification_id": "n_991",
  "selected_channels": ["PUSH", "IN_APP"],
  "deferred_channels": ["EMAIL"],
  "deferred_until": "2026-02-23T08:00:00-03:00",
  "policy_version": "route_policy_v12"
}

Fanout, Agendamento e Batching (Core 5)

Cenários

1. transacional unicast,
2. alerta para audiência pequena,
3. campanha para audiência grande.

Prioridades

• P0 transacional crítico,
• P1 transacional normal,
• P2 engajamento,
• P3 marketing bulk.

Diagrama

Trade-off

Batch melhora throughput e custo, mas aumenta latência. Ajustar janela por canal.

Pipelines por Provedor (Core 6)

Push

• alto throughput,
• entrega final nem sempre confirmável,
• token lifecycle importante.

Email

• accepted != inbox,
• bounce/complaint afeta reputação,
• warm-up de domínio é essencial.

SMS

• custo alto,
• regras regulatórias fortes,
• usar com prioridade e critério.

In-app

• barato e confiável para usuário ativo,
• excelente como canal complementar.

Isolamento

Conectores por canal devem ter isolamento de falha.

Deduplicação e Idempotência (Core 7)

Dedupe Key

(tenant_id, user_id, event_type, business_object_id, channel, dedupe_window)

Camadas de Dedupe

1. ingest (idempotency key do producer),
2. envio (message key por provider),
3. webhook (provider event id).

Tabela Exemplo

CREATE TABLE notification_dedupe (
  dedupe_key VARCHAR(256) PRIMARY KEY,
  notification_id VARCHAR(64) NOT NULL,
  created_at TIMESTAMP NOT NULL,
  expire_at TIMESTAMP NOT NULL
);

Retry, DLQ e Recuperação (Core 8)

Política de Retry

• exponential backoff + jitter,
• max attempts por canal,
• classificação de erro retryable x terminal.

Exemplo:

imediato, +5s, +30s, +2m, +10m, depois DLQ

Fluxo DLQ

1. move para DLQ,
2. classifica causa,
3. aciona remediação,
4. replay seguro com revalidação de preferência + dedupe.

Caching e Storage

Camadas

1. dedupe/schedule em Redis/KV,
2. metadata durável em SQL,
3. eventos em stream e warehouse.

Chaves de Cache

pref:user:{user_id}
consent:user:{user_id}:{channel}
template:{template_id}:{locale}:{version}
dedupe:{dedupe_key}
schedule:{notification_id}

TTLs

• dedupe: por semântica do evento,
• schedule: até estado terminal,
• templates: invalidação por versão.

Confiabilidade e Modos de Degradação

Falhas

1. outage de provider,
2. lag de fila,
3. indisponibilidade de preferência,
4. erro de template.

Estratégia

1. priorizar transacional sobre marketing,
2. pausar campanhas automaticamente,
3. fallback de canal para eventos críticos,
4. template minimal em degradação.

Matrix de Failover

Observabilidade e SLOs

SLOs

Golden Signals

1. latency enqueue->send por prioridade,
2. success/failure por provider,
3. bounce/complaint/unsubscribe,
4. volume suprimido por policy,
5. reprocessamentos DLQ.

Trace Campos

x-request-id
x-notification-id
x-user-id
x-channel
x-template-version
x-policy-version

Dicas de Entrevista

Estrutura

1. Defina classes de notificação.
2. Estime throughput e picos.
3. Desenhe pipeline event-driven.
4. Explique preferência/consentimento.
5. Explique dedupe/retry/DLQ.
6. Feche com compliance e SLO.

Erros Frequentes

1. ignorar opt-out/consent,
2. misturar transacional e marketing no mesmo fluxo,
3. sem dedupe,
4. sem isolamento de canal,
5. sem métrica operacional.

Script Curto

1. ingest + normalize,
2. preference gate,
3. route + render + dedupe,
4. schedule por prioridade/timezone,
5. dispatch por conectores isolados,
6. monitor e recuperar com DLQ.

Anti-Patterns

1) Enviar antes de checar preferência

Problema: violação de compliance e dano de marca.

Correção: gate de preferência antes do envio.

2) Fila única para tudo

Problema: campanha atrasa notificação crítica.

Correção: filas por prioridade.

3) Sem dedupe

Problema: usuário recebe duplicatas em retries/eventos repetidos.

Correção: dedupe multi-camada.

4) Conectores acoplados

Problema: falha de email derruba push.

Correção: isolamento por canal.

5) Sem estado de entrega claro

Problema: sem debug de falha real.

Correção: state machine + logs de attempt.

6) Ignorar quiet hours

Problema: UX ruim e risco regulatório.

Correção: scheduler timezone-aware.

7) Logar PII em excesso

Problema: risco de privacidade.

Correção: minimização e tokenização.

Conclusão

Sistema de notificação em escala é plataforma de decisão, não apenas "sender".

Arquitetura madura exige:

1. ingestão normalizada,
2. enforcement de preferência e consentimento,
3. roteamento e canalização isolada,
4. dedupe + idempotência robustos,
5. retries e DLQ operáveis,
6. observabilidade com foco em confiabilidade e compliance.

Esse tema é recorrente em entrevistas porque testa design distribuído, produto e operação ao mesmo tempo.

Referências

• RFC 8030 Web Push
• Firebase Cloud Messaging
• Apple APNS
• AWS SES
• Twilio SMS
• Google SRE Book
• Designing Data-Intensive Applications

Referência Rápida

Componentes

Regras Críticas

1. Preferência e consentimento antes de enviar.
2. Separar transacional de marketing.
3. Dedupe em múltiplas camadas.
4. Isolar falhas por canal.
5. Medir e agir com SLOs claros.

Resumo de 10 Minutos

1) Classes de notificação.
2) Ingest + normalize.
3) Preference/consent gate.
4) Route + render + dedupe.
5) Schedule por prioridade/timezone.
6) Dispatch com retry e DLQ.
7) Observabilidade + compliance.

Você agora tem um blueprint completo para sistema de notificações multicanal em escala global.