Projetar um Sistema de Notificações em Tempo Real Escalável

Design: Sistema de Notificação Escalável em Tempo Real 1. ARQUITETURA GERAL O sistema é composto por várias camadas distintas que trabalham juntas para ingerir eventos, roteá-los e enviá-los para clientes conectados com latência mínima. Camada de Cliente: Clientes móveis e web mantêm conexões WebSocket persistentes com um conjunto de servidores Connection Gateway. Cada cliente autentica ao conectar e registra seu ID de usuário com o gateway. API Gateway / Load Balancer: Um balanceador de carga de Camada 7 (por exemplo, AWS ALB ou NGINX) fica na frente dos Connection Gateways. Ele roteia novas requisições de upgrade WebSocket usando hashing consistente no ID do usuário, de modo que reconexões tendem a cair no mesmo nó do gateway, reduzindo a instabilidade de estado. Ele também expõe um endpoint REST para serviços internos publicarem eventos. Serviço de Publicação de Eventos: Serviços de plataforma internos (como serviço de usuário, serviço de comentários, serviço de amigos) publicam eventos em um message broker central. Eles chamam uma API de Publicação fina que valida o payload, enriquece-o com metadados (timestamp, ID da notificação) e o grava no broker. Message Broker (Kafka): Eventos são gravados em tópicos Kafka particionados por ID de usuário. Isso garante entrega ordenada por usuário e permite o escalonamento horizontal de consumidores. O log durável do Kafka também fornece a capacidade de replay necessária para garantias de entrega pelo menos uma vez. Serviço de Fanout de Notificações: Um pool de workers consumidores sem estado lê do Kafka. Para cada evento, o worker consulta as preferências de assinatura do usuário alvo em um cache rápido (Redis), determina quais usuários devem receber a notificação e, em seguida, roteia a mensagem para o Connection Gateway correto. Para eventos de alto fanout (por exemplo, uma postagem de celebridade), um trabalho de fanout assíncrono separado é acionado para evitar o bloqueio do caminho crítico. Connection Gateway (Servidores WebSocket): São servidores com estado que mantêm as conexões WebSocket abertas. Cada gateway mantém um mapa em memória de ID de usuário para handle de conexão. Quando uma notificação roteada chega (via um canal pub/sub interno como Redis Pub/Sub ou uma chamada gRPC direta), o gateway a envia pela conexão WebSocket apropriada. Se o usuário não estiver conectado, o gateway descarta o push e confia na camada de persistência para entrega posterior. Serviço de Presença e Roteamento: Um cluster Redis armazena um mapeamento de ID de usuário para ID do nó do gateway com um TTL curto, atualizado por heartbeats. O Serviço de Fanout consulta isso para saber para qual gateway rotear uma notificação. Se nenhuma entrada existir, o usuário está offline. Armazenamento de Notificações (Cassandra): Todas as notificações geradas são gravadas no Cassandra, com chave por ID de usuário e ordenadas por timestamp. Isso serve a dois propósitos: alimenta a UI da caixa de entrada de notificações (os usuários podem rolar pelas notificações passadas) e permite a entrega pelo menos uma vez — quando um usuário fica online, o cliente busca notificações não lidas deste armazenamento. Reconhecimento de Entrega: Clientes enviam uma mensagem ACK via WebSocket após receber uma notificação. O gateway grava este ACK no Kafka, e um consumidor marca a notificação como entregue no Cassandra. Notificações não reconhecidas mais antigas que um limite são reenfileiradas para entrega. 2. ESCOLHAS DE TECNOLOGIA E RACIOCÍNIO WebSockets sobre Long Polling ou SSE: WebSockets fornecem conexões persistentes full-duplex e de baixa sobrecarga. O Long Polling desperdiça recursos do servidor com handshakes HTTP repetidos e adiciona latência. Server-Sent Events (SSE) são unidirecionais e menos adequados para o fluxo de ACK. Com 1 milhão de conexões simultâneas, WebSockets são a escolha mais eficiente em termos de recursos. Cada conexão consome aproximadamente 10–50 KB de memória, tornando 1 milhão de conexões viáveis em um conjunto de gateways de tamanho moderado. Kafka sobre RabbitMQ: Kafka é escolhido por sua alta taxa de transferência (milhões de mensagens por segundo), armazenamento de log durável, semântica de grupo de consumidores e a capacidade de replay de mensagens. RabbitMQ é um bom broker para filas de tarefas, mas seu modelo de mensagens é menos adequado para os padrões de fanout e replay necessários aqui. O particionamento do Kafka por ID de usuário também paraleliza naturalmente o consumo. Com 10.000 notificações por segundo, o Kafka lida com isso com uma margem significativa. Redis para Presença e Pub/Sub: Redis fornece leituras de sub-milissegundos para a consulta de presença (ID de usuário → nó do gateway). Redis Pub/Sub ou Redis Streams podem ser usados para o canal interno entre o Serviço de Fanout e os Connection Gateways, adicionando latência mínima ao caminho de entrega. Cassandra sobre MySQL/PostgreSQL: O histórico de notificações é uma carga de trabalho pesada em escrita, de séries temporais, com alta cardinalidade (uma partição por usuário). O modelo de colunas largas do Cassandra, consistência ajustável e escalabilidade horizontal linear o tornam ideal. Um banco de dados relacional exigiria sharding complexo e lutaria com a taxa de transferência de escrita. A consistência eventual do Cassandra é aceitável aqui, pois o histórico de notificações não é um registro transacional. Workers de Fanout sem Estado: Manter os workers de fanout sem estado permite que eles escalem horizontalmente simplesmente adicionando mais instâncias de consumidor Kafka dentro do grupo de consumidores. 3. COMO O DESIGN ATENDE A CADA REQUISITO Escalabilidade (1 milhão de usuários simultâneos, 10.000 notificações/segundo): Os Connection Gateways são escaláveis horizontalmente. Um único servidor moderno pode manter 50.000–100.000 conexões WebSocket, então 10–20 nós de gateway lidam com 1 milhão de usuários. O balanceador de carga distribui novas conexões. As partições do Kafka escalam os workers de fanout. O Cassandra escala as escritas linearmente com os nós. O Cluster Redis particiona os dados de presença. Nenhum componente único é um gargalo. Latência (P99 < 200ms): O caminho crítico é: evento publicado → escrita no Kafka (~5ms) → worker de fanout consome e consulta presença no Redis (~5ms) → roteia para o gateway via Redis Pub/Sub ou gRPC (~5ms) → gateway envia via WebSocket (~10ms de rede). O total está bem abaixo de 50ms no caso mediano. O orçamento de P99 de 200ms acomoda o atraso do consumidor Kafka sob carga de pico e jitter de rede. Manter a lógica do worker de fanout simples e as consultas Redis em cache garante que o caminho crítico permaneça rápido. Confiabilidade (entrega pelo menos uma vez): As notificações são persistidas no Cassandra antes ou concomitantemente à tentativa de push. Se o push WebSocket falhar ou o cliente não ACK, a notificação permanece no estado não lido no Cassandra. Ao reconectar, o cliente busca notificações não lidas. O commit do offset do consumidor do Kafka é feito apenas após o worker de fanout ter roteado a mensagem com sucesso, garantindo que nenhum evento seja descartado silenciosamente. Isso fornece semântica de pelo menos uma vez de ponta a ponta. Disponibilidade (99,95% de uptime): Todos os componentes são implantados em múltiplas zonas de disponibilidade. O balanceador de carga, brokers Kafka, nós do Cluster Redis, nós Cassandra e workers de fanout rodam com redundância N+1 ou N+2. Falhas em nós de gateway fazem com que os clientes reconectem (lógica de reconexão WebSocket com backoff exponencial) e caiam em um nó saudável em segundos. O fator de replicação do Kafka de 3 garante que falhas de broker não causem perda de dados. O fator de replicação do Cassandra de 3 com leituras/escritas em quorum tolera falhas de nó. Esta arquitetura atinge confortavelmente 99,95% de uptime. 4. TRADE-OFFS Complexidade vs. Simplicidade: Este design tem muitas partes móveis — Kafka, Redis, Cassandra, gateways WebSocket, workers de fanout, serviço de presença. Isso é significativamente mais complexo de operar do que um sistema de polling simples ou uma configuração de broker único. O trade-off é justificado pelos requisitos de escala, mas exige uma prática de DevOps madura, boa observabilidade (rastreamento distribuído, métricas por componente) e expertise de plantão. Pelo Menos Uma Vez vs. Exatamente Uma Vez: A entrega exatamente uma vez exigiria transações distribuídas entre Kafka, Cassandra e o gateway, adicionando latência e complexidade significativas. Pelo menos uma vez é escolhido em vez disso, o que significa que um usuário pode ocasionalmente ver uma notificação duplicada. Isso é tratado no lado do cliente por deduplicação no ID da notificação. Para uma notificação de mídia social (um like ou comentário), um duplicado é um pequeno incômodo na experiência do usuário, não uma falha crítica — um trade-off aceitável. Gateways com Estado: Os gateways WebSocket são com estado (eles mantêm conexões ativas). Isso torna as implantações contínuas e a recuperação de falhas um pouco mais complexas do que um serviço totalmente sem estado. Os clientes devem implementar lógica de reconexão. O trade-off é que gateways com estado são necessários para push em tempo real; não há como enviar para um cliente sem uma conexão persistente. Fanout no Leitura vs. Escrita: Este design faz fanout no tempo de escrita (o worker de fanout envia para o gateway de cada destinatário imediatamente). Para usuários com milhões de seguidores, isso cria um problema de caminho crítico (a postagem de uma celebridade aciona milhões de operações de fanout). A mitigação é usar uma fila de trabalhos de fanout separada para contas acima de um limite de seguidores, processando-as assincronamente. O trade-off é que usuários com muitos seguidores podem experimentar latência de notificação ligeiramente maior, o que geralmente é aceitável. Confiabilidade do Redis Pub/Sub: O Redis Pub/Sub não persiste mensagens. Se um gateway estiver brevemente desconectado do Redis quando uma mensagem for publicada, ele a perderá. Isso é mitigado pela camada de persistência do Cassandra — o cliente buscará a notificação ao reconectar — mas significa que o push em tempo real é de melhor esforço, com o armazenamento persistente como rede de segurança. Usar Redis Streams em vez de Pub/Sub adicionaria persistência ao custo de um pouco mais de complexidade. Custo: Executar Kafka, Cluster Redis, Cassandra e um grande conjunto de gateways WebSocket é caro. Uma plataforma menor pode usar um serviço gerenciado como AWS SNS/SQS ou Firebase Cloud Messaging para reduzir o fardo operacional. Na escala descrita (1 milhão de usuários simultâneos), o controle e o desempenho de uma pilha personalizada justificam o custo.

Resumo de alto nível Proponho uma plataforma de notificação em tempo real, escalável horizontalmente e de baixa latência, construída em torno de: (1) infraestrutura de borda/gateway para aceitar eventos e conexões de clientes, (2) um backbone de pub/sub durável para rotear eventos para assinantes interessados, (3) gerenciadores de conexão / workers WebSocket que mantêm conexões de clientes ativas e executam fan-out, e (4) um armazenamento de presença rápido e um armazenamento de notificação durável para confiabilidade e entrega offline. O sistema usa particionamento e replicação para atingir metas de taxa de transferência e disponibilidade, com instrumentação de ponta a ponta, backpressure e idempotência para impor entrega pelo menos uma vez e baixa latência. 1) Arquitetura geral (componentes e fluxo de solicitação) Componentes principais - API Gateway / Ingress: Aceita publicações de eventos (de serviços internos) e atualizações de conexão de clientes. Expõe endpoints REST/gRPC para publicadores de eventos e lida com autenticação e limitação de taxa. Implantado atrás de LBs globais e endpoints por região. - Camada de Conexão (WebSocket / GRPC streams): Uma frota de servidores de conexão sem estado (WebSocket/HTTP2 ou gRPC) que mantêm conexões persistentes com os clientes. Eles executam roteamento leve e tratamento de reconhecimento e encaminham alterações de assinatura para o armazenamento de presença. - Armazenamento de Presença e Roteamento: Um armazenamento chave-valor de baixa latência (cluster Redis) que rastreia qual(is) servidor(es) de conexão hospeda(m) atualmente cada usuário online e quais tópicos eles assinam. Usado para rotear notificações para o worker de conexão correto. - Backbone Pub/Sub: Um barramento de mensagens durável e particionado (Kafka ou Apache Pulsar) usado para distribuir eventos de publicadores para workers de notificação. Os tópicos são particionados por chaves lógicas (ID do usuário, ID do tópico) para garantir processamento ordenado por chave e taxa de transferência escalável. - Serviço de Notificação / Pool de Workers: Consumidores do tópico pub/sub que realizam enriquecimento, filtragem e roteamento de entrega. Os workers consultam o armazenamento de presença para encontrar servidores de conexão de destino e enviam tarefas de entrega para caminhos de entrega rápidos. - Camada de Entrega / Mecanismo de Fan-out: Os servidores de conexão recebem solicitações de entrega (diretamente ou via RPC rápido) e enviam notificações pela conexão persistente para o cliente. Eles lidam com controle de fluxo por conexão, lotes e ACKs dos clientes. - Armazenamento de Notificação Durável (NoSQL): Um armazenamento replicado e otimizado para gravação (por exemplo, Cassandra / DynamoDB) para persistir notificações para usuários offline, retentativas e auditoria. Armazena cargas úteis de notificação, tentativas de entrega, timestamps, TTLs. - Armazenamento de Deduplicação e Idempotência: Pequeno armazenamento chave-valor (Redis ou RocksDB) para registrar IDs de mensagens recentes para deduplicação quando semânticas de pelo menos uma vez causam duplicatas. - Plano de Controle e Monitoramento: Métricas, rastreamento, SLO/alertas, disjuntores e limitação. Fluxos típicos - Fluxo de publicação (produtor de eventos -> usuário): 1) O publicador envia o evento para o API Gateway (REST/gRPC). 2) O gateway grava a mensagem no tópico Pub/Sub (particionado por tópico de destino/ID do usuário). 3) Os workers de notificação consomem eventos, enriquecem e resolvem listas de assinaturas (ou consultam o banco de dados de assinaturas), consultam o armazenamento de presença para encontrar destinatários online e, para cada conexão online, enviam para os servidores de conexão apropriados. 4) Os servidores de conexão enviam via stream WebSocket/gRPC para o cliente e aguardam um ACK leve. 5) Se o usuário estiver offline (falha na presença), grava no Armazenamento de Notificação Durável para recuperação offline. - Fluxo de assinatura: Os clientes enviam mensagens de assinatura/cancelamento de assinatura por meio de sua conexão persistente. O servidor de conexão atualiza o armazenamento de presença atomicamente para que o roteamento do worker veja as assinaturas atualizadas rapidamente. - Recuperação e repetição: O pub/sub durável e o Armazenamento de Notificação permitem a repetição de eventos perdidos; os servidores de conexão registram novamente a presença na reconexão. 2) Escolhas de tecnologia e justificativa - Conexão do cliente: WebSockets ou streams HTTP/2 (gRPC) - Escolha: WebSockets para ampla compatibilidade com clientes (móvel/web). Considere streams gRPC HTTP/2 para aplicativos internos/móveis que o suportam. Ambos mantêm conexões TCP/TLS persistentes para atender à latência <200ms. - Razão: O polling é muito lento e ineficiente. O long polling aumenta a latência e o uso de recursos. WebSockets fornecem push, baixo RTT e a capacidade de entregar mensagens binárias com pouca sobrecarga. - Backbone Pub/Sub: Apache Kafka ou Apache Pulsar - Escolha: Kafka (gerenciado como Confluent Cloud ou auto-hospedado) ou Pulsar se as necessidades de multilocação e replicação geográfica dominarem. - Razão: Ambos fornecem mensagens particionadas, duráveis e de alta taxa de transferência. Kafka tem ferramentas maduras, alta taxa de transferência, latência previsível e suporte a semântica exatamente uma vez em produtores. O particionamento permite escalar para 10k msg/s facilmente. Pulsar oferece replicação geográfica integrada se multi-região for necessário. - Armazenamento de presença e roteamento: Cluster Redis (em memória) com replicação - Razão: Leituras/gravações abaixo de 1ms para mapear usuário -> servidores de conexão, assinaturas e metadados de conexão. Redis suporta clustering, persistência (AOF/RDB) e pesquisas rápidas necessárias para rotear eventos dentro do orçamento de 200ms. - Armazenamento de notificação persistente: Cassandra / DynamoDB (NoSQL) - Escolha: Cassandra ou armazenamento chave-valor semelhante ao DynamoDB. - Razão: Alta taxa de transferência de gravação, escalabilidade linear e TTLs configuráveis, ideais para armazenar muitas gravações por segundo e atender a leituras offline. Sistemas SQL lutam nessa escala de gravações e complexidade de particionamento horizontal. - Servidores de conexão e comunicação do worker: gRPC/RPC interno + protobuf - Razão: Mensagens binárias de baixa sobrecarga, suporte a backpressure, tipagem forte e alto desempenho. - Balanceamento de carga e roteamento: Balanceadores de carga L4 (TCP) para WebSockets + LB L7 para APIs REST. Use roteamento fixo via hashing consistente ou afinidade de sessão para rotear reconexões para a mesma região. - Formato do payload do cliente: Binário compacto (protobuf/flatbuffers) para payloads menores e serialização mais rápida. 3) Como o design atende aos requisitos não funcionais - Escalabilidade (1 milhão de usuários simultâneos, pico de 10 mil notificações/s) - Servidores de conexão sem estado: Escala horizontal; cada servidor lida com N conexões WebSocket simultâneas. Com máquinas modernas (por exemplo, 100 mil soquetes por máquina com ajuste adequado), dezenas/centenas de servidores lidam com 1 milhão de soquetes simultâneos. Grupo de autoescalonamento + orquestração de contêineres gerencia a capacidade. - Pub/sub particionado (Kafka): Escala produtores e consumidores adicionando partições/workers. O particionamento por ID de usuário de destino ou tópico garante distribuição uniforme de carga. 10 mil msg/s é modesto para clusters Kafka dimensionados adequadamente (dezenas de brokers). - Armazenamento de presença particionado: O Cluster Redis particiona o espaço do usuário para que as consultas permaneçam O(1) e escalem. - Armazenamento durável particionado: Cassandra escala linearmente adicionando nós para gravações e leituras. - Latência (99% dentro de 200ms) - Conexões persistentes eliminam a sobrecarga do handshake TCP. Uma vez estabelecida, o push de publicação de evento para o cliente é: API Gateway -> Anexação Kafka (sub-ms-10s ms dependendo do ajuste) -> consumo do worker -> consulta de presença (sub-ms) -> RPC para o servidor de conexão -> push via WebSocket (sub-ms a alguns ms). Com posicionamento cuidadoso (implantar workers e servidores de conexão na mesma região/az), a latência da rede permanece pequena. Use lotes ajustados para entrega quase instantânea (evite atrasos de lote) e ajuste a configuração do consumidor Kafka (linger.ms baixo) para manter a latência de ponta a ponta baixa. - Implantação de borda/regional: Posicione os servidores de conexão perto dos clientes (nível regional) para minimizar a latência da última milha. - Use serialização binária e payloads pequenos para reduzir o tempo de serialização/rede. - Confiabilidade (entrega pelo menos uma vez) - Gravações duráveis: Publicadores gravam eventos no Kafka (durável), workers rastreiam offsets; as mensagens permanecem duráveis até serem reconhecidas pelo processamento do consumidor. - Pelo menos uma vez: Se a entrega falhar (crash do servidor de conexão, rede), o worker pode reenfileirar ou tentar novamente porque o pub/sub retém as mensagens e o worker confirma os offsets apenas após o enfileiramento/confirmação bem-sucedida. Os clientes confirmam o recebimento, mas os ACKs apenas confirmam a aceitação do cliente; a persistência do lado do servidor permite retentativas. - Deduplicação: Como pelo menos uma vez pode produzir duplicatas, inclua IDs de mensagem exclusivos e caches de deduplicação do lado do servidor ou do lado do cliente para suprimir duplicatas. - Armazenamento de Notificação Durável: Quando o usuário estiver offline ou quando a confirmação persistente for necessária, grave a notificação no Cassandra antes de confirmar o evento para que possa ser entregue posteriormente. - Disponibilidade (99,95% de tempo de atividade) - Implantação multi-AZ e multi-região: Replique componentes críticos. Use Kafka com fator de replicação >2, Redis com mestre-réplica e failover, Cassandra com várias réplicas e consistência ajustável. - Frontends sem estado e autoescalonamento: Se algum servidor de conexão falhar, os clientes se reconectam ao próximo servidor disponível. Use verificações de integridade e failover rápido. - Degradação graciosa: Se ocorrer sobrecarga de entrega, aceite eventos e persista-os para entrega posterior, em vez de descartá-los. Limitação e backpressure protegem o sistema. - Observabilidade e automação: Reinicialização automática, disjuntores e runbooks para intervenção do operador. SLOs e alertas ajustados para manter 99,95% de disponibilidade. 4) Detalhes operacionais e otimizações - Chaves de particionamento e roteamento: Particione o pub/sub por ID de usuário para mensagens direcionadas ao usuário e por ID de tópico para transmissões de tópico. Para fan-outs para muitos usuários (por exemplo, uma postagem curtida por milhares), execute fan-out hierárquico: 1) determine os destinatários; 2) agrupe os destinatários por servidor de conexão; 3) envie a mensagem de entrega agrupada para cada servidor de conexão para evitar chamadas NRPC. - Estratégias de Fan-out - Fan-out na gravação (push): Preferível para entrega online em tempo real — os workers enviam apenas para conexões online encontradas via armazenamento de presença. - Fan-out na leitura (pull): Use para fan-out offline grande ou para usuários com pouca frequência online; armazene a notificação e deixe os clientes buscarem quando online. - Loteamento e coalescência: Para eventos semelhantes de alto volume, coaleça vários eventos em uma notificação compacta quando seguro (por exemplo, “3 pessoas curtiram sua postagem”) para reduzir a carga e melhorar a experiência do usuário. - Backpressure e suavização: Se os servidores de conexão ou o cliente não puderem aceitar mensagens, aplique backpressure: diminua a velocidade dos consumidores, armazene em buffer no armazenamento durável e tente novamente. Implemente limites de taxa por cliente. - Modelo ACK do cliente: Use um ACK leve para recebimento bem-sucedido. Se o ACK não for recebido dentro do tempo limite, tente novamente a entrega. Mantenha contadores de tentativas de entrega e envie para o armazenamento de dead-letter após N tentativas. - Segurança e privacidade: Autenticação de ponta a ponta no gateway, verifique a permissão do publicador para publicar; criptografe o transporte (TLS) e sanitize os payloads. 5) Compromissos e discussão - Complexidade vs Simplicidade - Compromisso: Um sistema multi-componente baseado em Kafka é operacionalmente mais complexo do que um servidor de push simples, mas necessário para escala e confiabilidade. O custo operacional e a complexidade de engenharia aumentam (gerenciando Kafka, cluster Redis, Cassandra), mas fornecem durabilidade, repetição e controle de fan-out. - Pelo menos uma vez vs Exatamente uma vez - Escolha: Entrega pelo menos uma vez com deduplicação é escolhida. Exatamente uma vez de ponta a ponta é muito caro (coordenação entre serviços e clientes) e muitas vezes desnecessário para notificações onde duplicatas são toleráveis. Caches de deduplicação e idempotência do lado do cliente fornecem mitigação prática. - WebSockets vs gRPC HTTP/2 - Compromisso: WebSockets maximizam a compatibilidade, mas exigem mais ajuste de LB e conexão. gRPC oferece melhor controle de fluxo e segurança de tipo para clientes que o suportam. Suportar ambos adiciona complexidade, mas oferece a melhor cobertura. - Push em tempo real vs armazenamento primeiro - Push primeiro é priorizado para usuários online para atender à latência. No entanto, armazenamento primeiro (persistir no banco de dados primeiro) adiciona durabilidade ao custo de latência de gravação adicional. Buscamos um equilíbrio: gravar no Kafka (durável) rapidamente, opcionalmente persistir no Cassandra dependendo da política de confiabilidade. - Consistência eventual da presença Redis - A presença pode estar ligeiramente desatualizada em casos extremos; uma pequena janela de falsos negativos/positivos pode causar uma única notificação perdida que será recuperada do armazenamento de notificação durável. Este design favorece consultas de presença de baixa latência em valores de presença globais estritamente síncronos. 6) Planejamento de capacidade e números (estimativa rápida) - 1 milhão de usuários simultâneos: Se cada servidor de conexão lidar com ~10 mil WebSockets simultâneos, são necessários ~100 servidores de conexão. Adicione um fator de segurança (2x) para picos -> ~200 instâncias em todas as regiões. - 10 mil notificações/s: Cluster Kafka com 10–50 partições é suficiente dependendo do tamanho da mensagem e replicação; número alvo de brokers em torno de 5–10 com fator de replicação 3. Grupos de consumidores escalam horizontalmente. - Armazenamento: A 10 mil notificações/s, ~864 milhões de notificações por dia (se cada mensagem for persistida) — use TTLs e agregação para reduzir o armazenamento. Nós Cassandra dimensionados de acordo. 7) Modos de falha e mitigações - Crash do servidor de conexão: Clientes se reconectam a outros servidores; o armazenamento de presença é atualizado na reconexão. Mensagens em buffer no worker são retentadas. Use estratégias de reconexão fixas para reduzir a rotatividade de estado. - Falha do broker Kafka: A replicação de partição garante que não haja perda de dados quando o fator de replicação >=3 e ISR configurado. Monitore partições sub-replicadas. - Failover Redis: Use Cluster Redis com réplicas e failover automatizado (Sentinel ou serviços gerenciados). Reconstrua a presença dos servidores de conexão em caso de failover grande. - Fan-outs grandes (eventos virais): Use fan-out hierárquico e loteamento; descarregue para workers em segundo plano e persista notificações para entrega posterior se a entrega em tempo real violar a latência. Conclusão Este design usa conexões persistentes (WebSockets/gRPC), um pub/sub particionado durável (Kafka/Pulsar), um armazenamento de presença de baixa latência (Redis) e um armazenamento NoSQL escalável (Cassandra/DynamoDB) para atender às metas de 1 milhão de conexões simultâneas, 10 mil notificações/s, latência de 99% <200ms, confiabilidade pelo menos uma vez e disponibilidade de 99,95%. Os principais compromissos são o aumento da complexidade operacional e o tratamento de duplicatas. Com particionamento cuidadoso, replicação, monitoramento e ajuste de componentes individuais (configurações do consumidor, loteamento, backpressure), esta arquitetura escalará e fornecerá as notificações em tempo real de baixa latência e confiáveis que a plataforma precisa.