Projetar um Serviço de Notificações em Tempo Real

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.