Serviço de Notificação em Tempo Real — Design de Sistema de Alto Nível

================================================================================
0. ESTIMATIVA DE ORÇAMENTO

• 10M DAU × 20 notificações/usuário/dia = 200M notificações/dia
• 200M / 86.400s ≈ 2.315 notificações/segundo (média)
• Carga de pico (assumindo 5× média) ≈ 11.575 notificações/segundo
• Carga útil de cada notificação ~1 KB → ~200 GB/dia de ingestão de dados brutos
• Orçamento de latência: < 2 segundos ponta a ponta (ingestão → entrega ao dispositivo)

================================================================================

1. ARQUITETURA CENTRAL
   ================================================================================

O sistema segue uma arquitetura orientada a eventos e microsserviços com os seguintes componentes principais:

┌──────────────┐
│ Produtores │ (Serviço de Postagem, Serviço de Curtida, Serviço de Comentário, Serviço de Seguimento, etc.)
└──────┬───────┘
│ Evento de Notificação (gRPC / mensagem assíncrona)
▼
┌──────────────────┐
│ Gateway de API /│ Limitação de taxa, autenticação, roteamento
│ Balanceador de │ (por exemplo, AWS ALB / Envoy / Kong)
│ Carga │
└──────┬───────────┘
│
▼
┌──────────────────┐
│ Serviço de │ Serviço sem estado (escalável horizontalmente)
│ Notificação (SN)│ - Valida e desduplica eventos
│ │ - Enriquece com preferências do usuário
│ │ - Distribui para filas por canal
└──────┬───────────┘
│ Grava registro de notificação no BD
│ Publica na Fila de Mensagens
▼
┌──────────────────────────────────────────────────┐
│ Fila de Mensagens / Broker │
│ (Apache Kafka — particionado por hash de user_id)│
│ │
│ Tópicos: push_notifications │
│ email_notifications │
│ in_app_notifications │
└──┬──────────────┬─────────────────┬──────────────┘
│ │ │
▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌────────────────┐
│ Pool │ │ Pool │ │ Pool │
│ Push │ │ Email │ │ In-App │
│ Worker │ │ Worker │ │ Worker │
└─┬──────┘ └────┬─────┘ └───────┬────────┘
│ │ │
▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌────────────────┐
│ APNs / │ │ SES / │ │ Gateway │
│ FCM │ │ SendGrid │ │ WebSocket │
└────────┘ └──────────┘ │ (conexões │
│ persistentes) │
└────────────────┘

Descrições dos Componentes:

A) Gateway de API / Balanceador de Carga

• Ponto de entrada para serviços produtores internos e chamadas de API externas (por exemplo, marcar como lido).
• Lida com limitação de taxa, autenticação e roteamento de requisições.
• Distribui tráfego entre múltiplas instâncias do Serviço de Notificação.

B) Serviço de Notificação (SN)

• Microsserviço sem estado implantado em múltiplas réplicas atrás do balanceador de carga.
• Recebe eventos de notificação, valida-os, realiza desduplicação (verificação de chave de idempotência).
• Busca preferências de notificação do usuário em um cache (Redis) ou banco de dados.
• Determina em quais canais entregar (push, e-mail, in-app) com base nas preferências.
• Persiste o registro de notificação no banco de dados.
• Publica mensagens específicas do canal em tópicos do Kafka.

C) Fila de Mensagens (Apache Kafka)

• Desacopla a criação da notificação da entrega, absorvendo picos de tráfego.
• Particionado por hash de user_id para preservar a ordem por usuário.
• Oferece durabilidade (fator de replicação = 3) e capacidade de replay.
• Tópicos separados por canal permitem o escalonamento independente de consumidores.

D) Workers de Canal (Grupos de Consumidores)

• Pool de Workers Push: Consome do tópico push_notifications, agrupa requisições e envia para APNs (iOS) e FCM (Android). Lida com gerenciamento de tokens e lógica de retentativa.
• Pool de Workers de E-mail: Consome do tópico email_notifications, renderiza templates e envia via SES/SendGrid. Implementa backoff exponencial para falhas transitórias.
• Pool de Workers In-App: Consome do tópico in_app_notifications, envia para o Gateway WebSocket para entrega em tempo real. Volta para polling se o WebSocket estiver desconectado.

E) Gateway WebSocket

• Mantém conexões WebSocket persistentes com usuários online.
• Escalado horizontalmente; usa Redis Pub/Sub ou um barramento de mensagens compartilhado para que qualquer nó do gateway possa entregar para qualquer usuário conectado.
• Registro de conexão armazenado no Redis (mapeamento user_id → gateway_node).

F) API de Leitura de Notificações

• Caminho de leitura separado para buscar histórico de notificações, marcar como lido, gerenciar preferências.
• Servido a partir de réplicas de leitura / cache para evitar impactar o caminho de escrita.

================================================================================
2. ESQUEMA DO BANCO DE DADOS

Armazenamento de dados principal: PostgreSQL (para preferências e metadados) + Cassandra (para armazenamento de notificações em escala).

--- PostgreSQL (Preferências e Metadados do Usuário) ---

TABELA: users
user_id UUID PRIMARY KEY
email VARCHAR(255)
phone VARCHAR(50)
created_at TIMESTAMP
updated_at TIMESTAMP

TABELA: notification_preferences
user_id UUID PRIMARY KEY REFERENCES users(user_id)
push_enabled BOOLEAN DEFAULT TRUE
email_enabled BOOLEAN DEFAULT TRUE
in_app_enabled BOOLEAN DEFAULT TRUE
quiet_hours_start TIME NULLABLE
quiet_hours_end TIME NULLABLE
email_digest_freq ENUM('instant', 'hourly', 'daily') DEFAULT 'instant'
-- Sobrescritas por categoria
likes_push BOOLEAN DEFAULT TRUE
likes_email BOOLEAN DEFAULT FALSE
comments_push BOOLEAN DEFAULT TRUE
comments_email BOOLEAN DEFAULT TRUE
follows_push BOOLEAN DEFAULT TRUE
follows_email BOOLEAN DEFAULT FALSE
mentions_push BOOLEAN DEFAULT TRUE
mentions_email BOOLEAN DEFAULT TRUE
updated_at TIMESTAMP

TABELA: device_tokens
token_id UUID PRIMARY KEY
user_id UUID REFERENCES users(user_id)
platform ENUM('ios', 'android', 'web')
device_token VARCHAR(512)
is_active BOOLEAN DEFAULT TRUE
created_at TIMESTAMP
updated_at TIMESTAMP
INDEX idx_device_user (user_id)

--- Cassandra (Armazenamento de Notificações — otimizado para leituras de séries temporais) ---

TABELA: notifications
user_id UUID -- Chave de partição
created_at TIMEUUID -- Chave de clusterização (DESC)
notification_id UUID
type TEXT -- 'like', 'comment', 'follow', 'mention', 'system'
actor_id UUID
target_entity_type TEXT -- 'post', 'comment', 'profile'
target_entity_id UUID
message TEXT
is_read BOOLEAN
channels_delivered SET<TEXT> -- {'push', 'email', 'in_app'}
metadata TEXT -- Blob JSON para extensibilidade
PRIMARY KEY ((user_id), created_at)
WITH CLUSTERING ORDER BY (created_at DESC)
AND default_time_to_live = 7776000 -- TTL de 90 dias

TABELA: notification_counts (tabela de contagem/materializada)
user_id UUID PRIMARY KEY
unread_count COUNTER

--- Redis (Camada de Cache) ---

• Cache de preferências do usuário: Chave = pref:{user_id}, TTL = 10 min
• Cache de contagem não lida: Chave = unread:{user_id}, TTL = 5 min
• Conjunto de desduplicação: Chave = dedup:{idempotency_key}, TTL = 24 horas
• Registro de conexão WebSocket: Chave = ws:{user_id} → id_do_nó_gateway

================================================================================
3. ESTRATÉGIA DE ESCALONAMENTO

A) Escalonamento Horizontal de Serviços Sem Estado

• Serviço de Notificação, todos os Pools de Workers e Gateway WebSocket são sem estado e escaláveis horizontalmente.
• Grupos de autoescalonamento (HPA do Kubernetes) baseados em métricas de CPU, memória e atraso da fila.
• Meta: cada instância do SN lida com ~500 req/s; são necessárias ~25 instâncias no pico.

B) Particionamento do Kafka

• Começar com 64 partições por tópico (permite até 64 consumidores por grupo).
• Particionar por hash de user_id para garantias de ordem por usuário.
• Escalonar partições conforme o throughput aumenta (reparticionar com cuidado).
• Grupos de consumidores separados por canal permitem escalonamento independente.

C) Escalonamento do Banco de Dados

• Cassandra: Naturalmente escalável horizontalmente. Começar com um cluster de 6 nós (RF=3).
  Adicionar nós conforme o volume de dados cresce. Chave de partição = user_id distribui a carga uniformemente.
• PostgreSQL: Escalonamento vertical inicialmente para preferências (conjunto de dados relativamente pequeno: 10M de linhas).
  Adicionar réplicas de leitura para buscas de preferências com muitas leituras. Considerar sharding por user_id, se necessário.
• Cluster Redis: 3+ nós com sharding automático para cache e registro de conexão.

D) Escalonamento do Gateway WebSocket

• Cada nó do gateway lida com ~100K conexões simultâneas.
• 10M DAU com ~30% online simultâneo = 3M conexões → ~30 nós de gateway.
• Redis Pub/Sub ou um barramento de mensagens leve (por exemplo, NATS) para roteamento de mensagens entre nós.
• Hashing consistente para atribuição de usuário para nó com rebalanceamento gracioso.

E) Limitação de Taxa e Backpressure

• Limitar a taxa de produtores de notificação para evitar abusos (por exemplo, máx. 1000 eventos/segundo por produtor).
• Monitoramento de atraso do consumidor Kafka com alertas; escalar consumidores automaticamente quando o atraso exceder o limite.
• Disjuntores em serviços externos (APNs, FCM, SES) para evitar falhas em cascata.

F) Caminho de Crescimento Futuro

• Mover para uma implantação multirregional com Kafka MirrorMaker 2 para replicação entre regiões.
• Introduzir uma camada de agregação/agrupamento de notificações (por exemplo, "X e outros 5 curtiram sua postagem").
• Adicionar uma fila de prioridade para notificações sensíveis ao tempo (por exemplo, mensagens diretas vs. notificações de curtida).

================================================================================
4. CONFIABILIDADE E TOLERÂNCIA A FALHAS

A) Durabilidade dos Dados

• Kafka: Fator de replicação = 3, min.insync.replicas = 2, acks = all.
  Garante nenhuma perda de dados, mesmo se um broker falhar.
• Cassandra: Fator de replicação = 3, consistência de escrita = QUORUM (2 de 3).
  Tolera falha de nó único sem perda de dados.
• PostgreSQL: Replicação síncrona para pelo menos um standby.

B) Entrega Pelo Menos Uma Vez (At-Least-Once)

• Consumidores Kafka confirmam offsets apenas após o processamento bem-sucedido.
• Workers implementam entrega idempotente usando notification_id como chave de desduplicação.
• Se uma entrega push/e-mail falhar, a mensagem permanece no Kafka para retentativa.
• Fila de Mensagens Mortas (DLQ) para mensagens que falham após N retentativas (por exemplo, 5 retentativas com backoff exponencial).

C) Alta Disponibilidade (Meta de 99,9% = máx. 8,76 horas de inatividade/ano)

• Todos os serviços implantados em 3 Zonas de Disponibilidade (AZs).
• Kubernetes com regras de anti-afinidade de pods garante que as réplicas sejam distribuídas entre as AZs.
• Clusters de banco de dados abrangem múltiplas AZs com failover automático.
• Verificações de integridade do balanceador de carga com remoção automática de instâncias não íntegras.
• Implantações blue-green ou canary para minimizar a inatividade relacionada à implantação.

D) Degradação Graciosa

• Se o serviço de notificação push (APNs/FCM) estiver inativo, as notificações são enfileiradas no Kafka e retentadas.
• Se o gateway WebSocket estiver sobrecarregado, os clientes voltam a usar o polling da API de leitura de notificações.
• Se o Cassandra estiver temporariamente indisponível, as notificações são bufferizadas no Kafka (que tem retenção de vários dias).
• Padrão de disjuntor em todas as dependências externas com comportamento de fallback.

E) Monitoramento e Alerta

• Rastreamento de latência ponta a ponta: timestamp na criação → timestamp na entrega (P50, P95, P99).
• Monitoramento de atraso do consumidor Kafka por tópico e grupo de consumidores.
• Dashboards de taxa de erro por canal (taxa de falha push, taxa de rejeição de e-mail).
• Alertas em: latência > 2s em P95, atraso do consumidor > 10K mensagens, taxa de erro > 1%, disponibilidade < 99,9%.

F) Recuperação de Desastres

• Dados de tópicos Kafka retidos por 7 dias, permitindo replay de qualquer ponto.
• Snapshots do Cassandra tirados diariamente, armazenados no S3 com replicação entre regiões.
• Arquivamento WAL do PostgreSQL para S3 para recuperação em ponto no tempo.
• Runbook para recuperação completa do cluster com RTO alvo < 1 hora, RPO < 5 minutos.

================================================================================
5. PRINCIPAIS COMPROMISSOS (TRADE-OFFS)

Compromisso 1: Disponibilidade vs. Consistência Estrita (AP sobre CP)

Decisão: Escolhemos consistência eventual para entrega de notificações e status de leitura.

• Cassandra com escritas QUORUM fornece consistência forte o suficiente para notificações, priorizando disponibilidade e tolerância a partições.
• Um usuário pode ver brevemente uma contagem não lida desatualizada (em cache no Redis com TTL de 5 minutos), mas isso é aceitável para um sistema de notificação onde a precisão em tempo real das contagens não é crítica.
• A alternativa — usar um banco de dados estritamente consistente como o PostgreSQL para todo o armazenamento de notificações — criaria um gargalo de escalonamento em 200M de escritas/dia e arriscaria a disponibilidade durante partições de rede.
• Impacto: Os usuários podem ocasionalmente ver uma contagem de notificações que está errada em 1-2 por alguns segundos. Este é um problema menor de UX em comparação com o risco de todo o sistema de notificação se tornar indisponível.

Compromisso 2: Modelo Push (WebSockets) vs. Modelo Pull (Polling) para Notificações In-App

Decisão: Escolhemos um modelo primeiro push usando WebSockets com polling como fallback.

• Push via WebSockets entrega notificações em tempo real (sub-segundo), atendendo ao nosso requisito de latência <2s.
• No entanto, manter milhões de conexões persistentes consome muitos recursos (~30 nós de gateway para 3M de conexões simultâneas) e adiciona complexidade operacional (gerenciamento de conexão, heartbeats, lógica de reconexão).
• A alternativa — polling puro — seria mais simples de operar, mas aumentaria a latência (se o intervalo de polling for longo) ou aumentaria drasticamente a carga do servidor (se o intervalo de polling for curto). Com 3M de usuários simultâneos fazendo polling a cada 2 segundos = 1,5M de req/s apenas para polling, o que é muito mais caro do que manter conexões WebSocket.
• Compromisso: Usamos WebSockets para usuários online e voltamos ao polling (com intervalos mais longos) quando as conexões WebSocket não podem ser estabelecidas (por exemplo, firewalls restritivas). Notificações push via APNs/FCM lidam com o caso em que o usuário está offline.

Compromisso 3: Armazenamento Único de Notificações (Cassandra) vs. Persistência Poliglota

Decisão: Usamos Cassandra para armazenamento de notificações e PostgreSQL para preferências/metadados do usuário em vez de um único banco de dados para tudo.

• Cassandra se destaca em escritas de séries temporais de alto throughput (200M/dia) e leituras baseadas em chave de partição (buscar notificações para um usuário), que é o padrão de acesso dominante.
• PostgreSQL é mais adequado para a natureza relacional das preferências do usuário (joins com a tabela de usuário, atualizações transacionais de preferências).
• O compromisso é o aumento da complexidade operacional (dois sistemas de banco de dados para manter, monitorar e fazer backup) e a necessidade de manter os dados consistentes entre os sistemas (por exemplo, se um usuário for excluído, as notificações devem ser limpas no Cassandra).
• Mitigamos isso com um processo de limpeza orientado a eventos: eventos de exclusão de usuário acionam trabalhos de limpeza assíncronos no Cassandra.

Compromisso 4: Pelo Menos Uma Vez vs. Entrega Exatamente Uma Vez

Decisão: Escolhemos semântica de entrega pelo menos uma vez com desduplicação no nível do aplicativo.

• Entrega exatamente uma vez em sistemas distribuídos é extremamente cara e complexa (requer transações distribuídas ou semântica exatamente uma vez do Kafka com sobrecarga de desempenho significativa).
• Pelo menos uma vez é mais simples e mais performático. Notificações duplicadas são tratadas na camada de aplicativo usando chaves de idempotência (notification_id verificado antes da entrega).
• O risco é que, em cenários de falha raros, um usuário possa receber uma notificação push duplicada. Isso é um incômodo menor em comparação com o risco de notificações perdidas (no máximo uma vez) ou o custo de complexidade/desempenho de exatamente uma vez.

================================================================================
RESUMO

Este design lida com 200 milhões de notificações/dia em três canais com latência de entrega inferior a 2 segundos. A arquitetura orientada a eventos com Kafka como sistema nervoso central fornece durabilidade, desacoplamento e tratamento natural de backpressure. Cassandra fornece armazenamento de notificações escalável horizontalmente, enquanto o gateway WebSocket permite entrega in-app em tempo real. O sistema é projetado para 99,9% de disponibilidade por meio de implantação multiaz, replicação em todas as camadas e padrões de degradação graciosa. Os principais compromissos favorecem disponibilidade, escalabilidade e simplicidade operacional em detrimento de consistência estrita e semântica exatamente uma vez, que são escolhas apropriadas para um sistema de notificação onde a inconsistência ocasional ou duplicatas raras são aceitáveis.

Design de alto nível

1. Arquitetura principal

Um bom design é orientado a eventos, ciente de canais e prioriza a durabilidade.

Fluxo principal

• Serviços de produto como Curtidas, Comentários, Seguir, Menções, Mensagens publicam eventos que merecem notificação.
• A API Gateway ou a API interna de Ingestão de Eventos recebem solicitações diretas, se necessário, mas a maior parte do tráfego deve vir de fluxos de eventos internos.
• O Orquestrador de Notificações valida o evento, o desduplica, expande os destinatários, verifica as preferências do usuário, cria um registro de notificação durável e emite trabalhos de entrega por canal.
• A Fila de Mensagens / Barramento de Eventos armazena em buffer o trabalho para os trabalhadores de canal downstream.
• Os Trabalhadores de Canal lidam com a entrega push, por e-mail e no aplicativo de forma independente.
• O serviço de status de entrega atualiza o estado da notificação e tenta novamente quando necessário.
• As APIs de Leitura fornecem a caixa de entrada de notificações e contagens de não lidas para os clientes.
• O Gateway WebSocket / SSE pode enviar atualizações no aplicativo em tempo real para usuários online.

Componentes chave

• API Gateway

  • Autenticação, limitação de taxa, roteamento, observabilidade.
  • Usado para APIs de leitura do cliente e APIs de administração.

• Barramento de Eventos / Fluxo de Ingestão

  • Log durável estilo Kafka / Pulsar.
  • Produtores: grafo social, conteúdo, mensagens, moderação, etc.
  • Tópico particionado por user_id do destinatário para preservar a ordenação por usuário quando útil.

• Orquestrador de Notificações

  • Serviço sem estado consumindo eventos.
  • Responsabilidades:
    • validar esquema
    • verificação de idempotência usando event_id ou chave de desduplicação
    • decisão de fanout
    • consulta de preferência
    • seleção de modelo
    • classificação de prioridade
    • persistência do registro de notificação canônico
    • enfileirar tarefas de entrega por canal
  • Grava primeiro, depois agenda a entrega, para que os dados não sejam perdidos.

• Serviço de Preferências

  • Retorna configurações de canal em nível de usuário, horários de silêncio, tokens de dispositivo, localidade, status de verificação de e-mail.
  • Suportado por um armazenamento de preferências de usuário fortemente consistente mais cache.

• Armazenamento de Notificações

  • Armazenamento durável canônico para metadados de notificação e registros de caixa de entrada do usuário.
  • Otimizado para gravações e leituras recentes.

• Fila de Entrega

  • Filas/tópicos separados por canal: push, e-mail, no aplicativo.
  • Permite diferentes políticas de retentativa e taxa de transferência.

• Trabalhador Push

  • Integra-se com APNS/FCM.
  • Lida com invalidação de token, cargas úteis específicas da plataforma, backoff exponencial.

• Trabalhador de E-mail

  • Integra-se com o provedor de e-mail.
  • Prioridade menor que push/no aplicativo para a maioria dos eventos sociais.
  • Rastreia bounces, reclamações, lista de supressão.

• Trabalhador de Entrega no Aplicativo

  • Grava no armazenamento da caixa de entrada e, se o usuário estiver online, envia via WebSocket/SSE.
  • Se offline, a notificação permanece disponível através da consulta da API da caixa de entrada.

• Gateway em Tempo Real

  • Mantém conexões persistentes de clientes para usuários ativos.
  • Assina eventos de entrega no aplicativo e envia em menos de 2 segundos.

• API de Leitura / Serviço de Caixa de Entrada

  • Lista notificações, marca como lida, contagem de não lidas, paginação.
  • Lê do armazenamento da caixa de entrada de notificações e cache.

• Processador de Retentativa / Dead Letter

  • Tenta novamente falhas transitórias.
  • DLQ para mensagens venenosas ou falhas permanentes.
  • Suporta replay.

• Pilha de Observabilidade

  • Métricas: latência de enfileiramento para entrega, taxa de sucesso por canal, contagens de retentativa, lag da fila.
  • Logs e rastreamento distribuído.
  • Alertas sobre violações de SLA.

Sequência de interação

• Um serviço de comentários emite o evento CommentCreated.
• O barramento de eventos armazena o evento de forma durável.
• O Orquestrador de Notificações consome o evento, determina o usuário destinatário, verifica as preferências, cria uma linha de notificação e emite trabalhos para:
  • fila no aplicativo
  • fila push se habilitada e urgente o suficiente
  • fila de e-mail se configurada
• O trabalhador no aplicativo armazena o item da caixa de entrada e envia via WebSocket se o usuário estiver online.
• O trabalhador push envia para FCM/APNS.
• Recibos de entrega/atualizações de status são gravados de volta.
• O usuário pode buscar a caixa de entrada completa através da API de leitura.

Estimativa de taxa de transferência

• 10M DAU × 20 notificações/dia = 200M notificações/dia.
• Taxa de transferência média = cerca de 2.315 notificações/seg.
• Sistemas reais têm picos, portanto, projete com pelo menos 10x de margem de pico: 20k a 30k criações de notificações/seg, com fanout de canal tornando a entrega downstream maior.
• Essa escala é muito gerenciável com filas particionadas e trabalhadores sem estado escalados horizontalmente.

2. Esquema do banco de dados

Use um modelo dividido:

• armazenamento durável transacional para registros de notificação canônicos e preferências
• cache para leituras frequentes
• armazenamento opcional de pesquisa/índice para consultas avançadas de caixa de entrada

Esquema básico

users_notification_preferences

• user_id PK
• push_enabled booleano
• email_enabled booleano
• in_app_enabled booleano
• quiet_hours_start
• quiet_hours_end
• timezone
• locale
• email_address
• email_verified booleano
• push_tokens json / tabela separada
• notification_type_settings json ou tabela filha normalizada
• updated_at

user_device_tokens

• token_id PK
• user_id
• platform
• device_token
• app_version
• last_seen_at
• is_active
• unique(device_token)
• index(user_id)

notifications

• notification_id PK
• recipient_user_id
• actor_user_id anulável
• type
• object_type
• object_id
• dedupe_key
• title
• body
• payload json
• priority
• created_at
• expire_at anulável
• aggregation_key anulável
• source_event_id único
• índices:
  • (recipient_user_id, created_at desc)
  • (recipient_user_id, notification_id)
  • unique(source_event_id) ou unique(dedupe_key)

notification_deliveries

• delivery_id PK
• notification_id
• channel enum(push, email, in_app)
• status enum(pending, sent, delivered, failed, suppressed)
• provider_message_id anulável
• attempt_count
• last_attempt_at
• next_retry_at anulável
• failure_reason anulável
• delivered_at anulável
• índices:
  • (notification_id)
  • (channel, status, next_retry_at)

notification_reads

• notification_id
• user_id
• read_at
• chave primária(notification_id, user_id)
• index(user_id, read_at)

Otimização opcional: tabela user_inbox

• user_id
• notification_id
• created_at
• read_state
• chave primária(user_id, created_at, notification_id)
  Esta pode ser a tabela principal em um armazenamento de colunas largas para recuperação da caixa de entrada.

Escolhas de armazenamento

• Preferências: banco de dados relacional ou armazenamento chave-valor fortemente consistente.
• Notificações/caixa de entrada: Cassandra/DynamoDB/Bigtable-estilo KV de coluna larga é atraente porque o padrão de acesso é principalmente por user_id e leituras recentes ordenadas por tempo, com volume de gravação muito alto.
• Auditoria/status de entrega: armazenamento relacional ou KV dependendo das necessidades de relatórios.
• Cache: Redis para contagens de não lidas e páginas recentes da caixa de entrada.

3. Estratégia de escalonamento

Escalonamento horizontal

• Todos os serviços sem estado escalam horizontalmente: orquestrador, trabalhadores de canal, APIs de leitura, gateways WebSocket.
• Particione os tópicos de eventos por recipient_user_id para distribuir a carga uniformemente e preservar a ordenação por usuário.
• Separe as filas por canal e prioridade para que o backlog de e-mail não afete a latência do push.

Escalonamento de dados

• Particione os dados de notificação por user_id.
• Use agrupamento por tempo, se necessário, para usuários muito grandes, por exemplo, chave de partição (user_id, mês).
• TTL para notificações mais antigas de baixo valor após a política de retenção, se o negócio permitir, enquanto arquiva em armazenamento de objetos barato.
• Cache de contagens de não lidas e as últimas N notificações.

Modelagem de tráfego

• Faixas de prioridade:
  • alta: menções diretas, mensagens, alertas de segurança
  • média: comentários, curtidas
  • baixa: atividade em resumo ou itens promocionais
• Durante picos, proteja primeiro as notificações de alta prioridade.
• Agrupe a geração de e-mails de baixa prioridade.

Estratégia de fanout

• Prefira fanout-on-write para caixa de entrada por usuário e canais em tempo real porque o alvo de latência é inferior a 2 segundos.
• Para eventos de fanout extremamente grandes, como postagens de celebridades para milhões, use tratamento híbrido:
  • crie um evento grosseiro uma vez
  • fanout assíncrono em lotes
  • potencialmente degrade canais não críticos para entrega em resumo ou atrasada
    Isso evita estampagens.

Escalonamento geográfico

• Ativo-ativo multirregional para APIs de ingestão e entrega.
• Mantenha a afinidade do usuário com a região de origem quando possível para reduzir gravações entre regiões.
• Replique metadados críticos globalmente.
• Provedores de canal são chamados da região mais próxima.

Planejamento de capacidade

• 200M/dia de notificações canônicas.
• Se cada uma criar 2 a 3 tentativas de canal em média, os registros de entrega downstream podem ser de 400M a 600M/dia.
• Use partições de fila dimensionadas para a taxa de transferência de pico, por exemplo, dezenas a centenas de partições dependendo do broker.
• Gateway WebSocket dimensionado pelo número de usuários online concorrentes, não por DAU.

4. Confiabilidade e tolerância a falhas

Alvo de disponibilidade: 99,9%

• Implantação Multi-AZ para cada camada.
• Nenhum ponto único de falha.
• Balanceadores de carga entre instâncias.
• Broker e DB gerenciados com replicação.

Sem perda de dados de notificação

• Persista a notificação canônica antes das tentativas de entrega.
• Use log/fila durável com fator de replicação >= 3.
• Consumidores idempotentes e retentativas do produtor.
• Padrão Outbox para serviços produtores upstream se eles emitirem eventos de notificação de operações transacionais.
  • Exemplo: uma gravação de comentário e um evento de notificação são vinculados usando transação de DB + outbox para evitar eventos perdidos.
• Capacidade de replay do log de eventos e DLQ.

Tratamento de falhas

• Entrega pelo menos uma vez internamente, com desduplicação nas camadas de orquestrador e canal.
• Retentativas de backoff exponencial para falhas transitórias do provedor.
• DLQ para tarefas malformadas ou que falham repetidamente.
• Disjuntores em torno de provedores APNS/FCM/e-mail.
• Comportamento de fallback:
  • se o provedor push estiver degradado, ainda armazene a notificação no aplicativo
  • se o provedor de e-mail estiver inativo, mantenha na fila e tente novamente mais tarde

Consistência e integridade dos dados

• source_event_id único ou dedupe_key evita a criação de notificações duplicadas.
• Máquina de estado de entrega evita transições inválidas.
• Consistência forte para atualizações de preferências se um efeito imediato for necessário, caso contrário, consistência limitada via invalidação de cache.

Recuperação de desastres

• Metadados e backups replicados entre regiões.
• Instantâneos periódicos mais WAL/binlog ou retenção de fluxo.
• RPO definido perto de zero usando log durável replicado.
• RTO minimizado com infraestrutura como código e design de standby quente/ativo-ativo.

Confiabilidade operacional

• SLOs para latência de enfileiramento para persistência e persistência para entrega.
• Alarmes de lag da fila.
• Sondas sintéticas para caminhos push/e-mail/no aplicativo.
• Controles de backpressure quando os provedores downstream limitam a taxa.
• Limites de taxa por locatário/tipo de evento para conter abusos.

5. Principais compensações

Compensação 1: Entrega pelo menos uma vez vs entrega exatamente uma vez

• Escolhido: pelo menos uma vez com idempotência.
• Por quê: exatamente uma vez entre brokers, bancos de dados e provedores externos como APNS/FCM/e-mail é caro e muitas vezes impraticável.
• Impacto: tentativas duplicadas ocasionais são possíveis, mas chaves de desduplicação e gravações idempotentes tornam as duplicatas visíveis para o usuário raras.
• Benefício: muito mais simples e confiável sob falha.

Compensação 2: Armazenamento de colunas largas/KV vs banco de dados relacional para caixa de entrada de notificações

• Escolhido: armazenamento de colunas largas ou estilo Dynamo para caixa de entrada, relacional para preferências e alguns metadados.
• Por quê: a carga de trabalho de notificação é de alta gravação, pesada em anexos e principalmente leituras por usuário e recência.
• Impacto: capacidade de consulta ad hoc mais fraca e modelagem de dados mais cuidadosa.
• Benefício: escala horizontal muito melhor e desempenho previsível.

Compensação 3: Fanout-on-write vs fanout-on-read

• Escolhido: principalmente fanout-on-write.
• Por quê: requisito de latência inferior a 2 segundos e necessidade de imediatismo push/no aplicativo.
• Impacto: mais amplificação de gravação, especialmente para eventos de alto fanout.
• Mitigação: abordagem híbrida para casos de mega-fanout.

Compensação 4: Entrega em tempo real push vs caixa de entrada apenas pull

• Escolhido: híbrido.
• Por quê: push/WebSocket oferece baixa latência para usuários ativos, API pull oferece resiliência para usuários offline.
• Impacto: mais complexidade do sistema porque o estado da conexão e a persistência da caixa de entrada são necessários.
• Benefício: melhor experiência do usuário e confiabilidade.

Resumo da arquitetura final sugerida

• Ingerir eventos através de um barramento de eventos durável.
• Usar um Orquestrador de Notificações sem estado para desduplicar, verificar preferências, persistir registros de notificação e publicar trabalhos específicos do canal.
• Armazenar dados da caixa de entrada em um armazenamento particionado por usuário escalável horizontalmente, com KV relacional ou fortemente consistente para preferências.
• Entregar via trabalhadores dedicados de push, e-mail e no aplicativo.
• Usar WebSocket/SSE para atualizações em tempo real no aplicativo e APIs de leitura normais para recuperação da caixa de entrada.
• Garantir a confiabilidade através de implantação Multi-AZ, filas replicadas, gravações com prioridade de durabilidade, idempotência, retentativas, DLQs, replay e recuperação de desastres entre regiões.

Este design suporta confortavelmente 10M DAU e 200M notificações/dia, ao mesmo tempo em que atende a entrega em menos de 2 segundos para a maioria das notificações em tempo real e mantém 99,9% de disponibilidade sem perda de dados.