Projetar um Serviço de Notificações Escalável

Um serviço de notificação escalável deve ser construído como uma plataforma assíncrona e orientada a eventos que separa a ingestão de eventos, a avaliação de preferências, a persistência de notificações, a entrega específica do canal e o rastreamento da entrega. O princípio de design mais importante é que os sistemas de produtos de origem, como seguidores, curtidas, comentários e mensagens diretas, não devem chamar síncronamente provedores de push móvel, provedores de e-mail ou dispositivos de usuário. Eles devem publicar eventos duráveis em uma camada de mensagens, e a plataforma de notificação deve processar esses eventos de forma independente com fortes garantias de retentativa e idempotência. Em um nível alto, a arquitetura contém estes componentes: produtores de eventos, uma API de ingestão, um log de eventos durável, processadores de notificação, um serviço de preferência do usuário, um serviço de template e personalização, um armazenamento de notificações, filas de fanout de canal, workers de entrega específicos do canal, integrações de provedores de terceiros, um gateway em tempo real para entrega no aplicativo e infraestrutura de observabilidade/retentativa. Serviços de produto geram eventos de notificação quando ocorrem ações voltadas para o usuário. Por exemplo, o serviço de grafo social emite um evento de novo seguidor, o serviço de postagem emite um evento de curtida ou comentário, e o serviço de mensagens emite um evento de mensagem direta. Cada evento contém um ID de evento, tipo de evento, ID do usuário ator, ID do usuário destinatário ou conjunto de destinatários, ID do objeto, timestamp de criação e metadados necessários para renderização. Os produtores enviam esses eventos para uma API de ingestão de notificação ou diretamente para um barramento de mensagens durável. A API de ingestão valida o esquema, autentica o produtor, atribui ou verifica uma chave de idempotência e grava o evento no log durável antes de confirmar o produtor. Isso evita a perda de notificações se os processadores downstream falharem. Para o backbone de mensagens duráveis, eu usaria Apache Kafka, Amazon MSK, Google Pub/Sub ou Pulsar. Kafka/Pulsar são boas opções porque fornecem alto throughput, ordenação particionada, retenção, replay, grupos de consumidores e armazenamento durável. A 50.000 solicitações de notificação por segundo, o stream de eventos deve ser particionado por ID de usuário destinatário para ordenação em nível de usuário onde necessário, ou por ID de evento quando a ordenação estrita por usuário for menos importante. O particionamento por destinatário ajuda a evitar notificações no aplicativo fora de ordem para um único usuário, mas pode criar partições quentes para contas de celebridades ou eventos de grupo. Para casos de fanout grandes, como um evento produzindo notificações para milhões de seguidores, um serviço de fanout separado deve dividir os destinatários em lotes e publicar jobs de notificação derivados por destinatário em muitas partições. Processadores de notificação consomem eventos brutos do log de eventos durável. Suas responsabilidades são determinar destinatários, buscar preferências do usuário, aplicar limites de taxa e horários de silêncio, deduplicar eventos, gerar registros de notificação específicos do canal e publicar jobs de entrega. Para eventos diretos como um comentário em uma postagem de um usuário, o conjunto de destinatários é pequeno. Para eventos de fanout como uma celebridade postando, o processador deve evitar fazer todo o fanout de forma síncrona. Ele deve criar um job de fanout e processar destinatários em shards, usando leituras em lote do store de grafo social. Isso evita que um evento muito grande bloqueie o caminho de baixa latência para notificações normais. O serviço de preferência do usuário armazena configurações como se um usuário deseja notificações push, no aplicativo ou por e-mail para curtidas, comentários, seguidores e mensagens diretas. As preferências devem ser armazenadas em um banco de dados altamente disponível como DynamoDB, Cassandra, ScyllaDB ou um banco de dados relacional sharded. O padrão de acesso é principalmente consulta chave-valor por ID de usuário e tipo de notificação, então um store distribuído de chave-valor ou coluna larga é apropriado. Para atender à meta de latência de 2 segundos, as preferências também devem ser cacheadas em Redis, Memcached ou um cache local em memória com TTLs curtos. Atualizações de preferência são gravadas no banco de dados source-of-truth e propagadas para caches através de eventos de invalidação. A troca é que a staleness do cache pode fazer com que uma preferência alterada recentemente leve alguns segundos para ser aplicada; se a consistência estrita de preferência for necessária, os processadores podem ler diretamente do banco de dados em caso de cache miss ou para usuários recentemente atualizados. O serviço de template e personalização renderiza o conteúdo da notificação. Ele mapeia tipos de evento para templates como “Alex curtiu sua postagem” ou “Maya comentou: ...”. Ele lida com localização, deep links, URLs de imagem e restrições de payload específicas do canal. Definições de template podem ser armazenadas em um banco de dados de configuração e cacheadas agressivamente porque mudam com pouca frequência. A renderização deve ocorrer antes que os jobs de entrega sejam publicados para que cada job seja autônomo e possa ser retentado com segurança. O store de notificações é a fonte da verdade para notificações no aplicativo visíveis ao usuário e estado de entrega. Uma boa opção é Cassandra, DynamoDB, ScyllaDB ou outro store horizontalmente escalável particionado por ID de usuário destinatário e ordenado por timestamp de notificação. O padrão de acesso primário é “buscar as últimas notificações para o usuário X”, então a tabela pode usar recipient_user_id como chave de partição e created_at ou notification_id como chave de ordenação. O serviço grava um registro de notificação no aplicativo antes ou atomicamente com a publicação do job de entrega no aplicativo. Registros incluem ID da notificação, destinatário, tipo, conteúdo, status, estado lido/não lido, timestamps e chave de deduplicação. Este store garante que mesmo que a entrega WebSocket falhe, o usuário ainda possa ver a notificação ao abrir o aplicativo. Após as preferências e templates serem aplicados, o processador publica jobs em filas de canal separadas: fila push, fila no aplicativo e fila de e-mail. Separar filas é importante porque cada canal tem características de latência e confiabilidade diferentes. Filas push e no aplicativo são sensíveis à latência e devem ser provisionadas para alto throughput com backlog mínimo. E-mail é menos sensível à latência e pode tolerar atrasos mais longos, throttling de provedor e batching. Filas separadas também evitam que um provedor de e-mail lento afete a entrega push. Workers de entrega push consomem da fila push e enviam notificações para Apple Push Notification service, Firebase Cloud Messaging ou outros provedores de push móvel. Tokens de dispositivo são armazenados em um registro de dispositivo com chave por ID de usuário, com token, plataforma, versão do aplicativo, localidade e timestamp de última visualização. O registro pode usar um store de chave-valor distribuído e cachear tokens ativos. Workers push devem lidar com respostas do provedor, remover tokens inválidos, retentar falhas transitórias com backoff exponencial e registrar tentativas de entrega. Confirmações do provedor push não garantem que o usuário viu a notificação, apenas que o provedor a aceitou, então o sistema deve distinguir a aceitação do provedor do recebimento real do usuário. A entrega no aplicativo tem dois caminhos. Primeiro, a notificação é persistida no store de notificações. Segundo, um worker de entrega no aplicativo a envia para os dispositivos atualmente conectados do usuário através de um gateway em tempo real. O gateway pode ser implementado usando WebSockets, streams HTTP/2 ou uma infraestrutura de conexão persistente semelhante a push móvel. Nós de gateway mantêm o estado da conexão do usuário em memória e publicam informações de presença para um serviço de presença distribuído. Uma camada de roteamento ou mapa de presença baseado em Redis/NATS informa ao worker no aplicativo qual nó de gateway atualmente possui a conexão de um usuário. Se o usuário estiver offline ou o envio do gateway falhar, nenhuma notificação é perdida porque a notificação persistida será buscada através da API de caixa de entrada de notificações do aplicativo na próxima sessão. Para baixa latência, os nós de gateway devem ser implantados regionalmente perto dos usuários e a fila no aplicativo deve ser processada por workers na mesma região, sempre que possível. Workers de entrega de e-mail consomem da fila de e-mail e enviam através de provedores como SES, SendGrid ou Mailgun. Eles devem suportar failover de provedor, tratamento de bounces, listas de supressão, conformidade de cancelamento de inscrição e limites de taxa por provedor. Notificações por e-mail podem ser agrupadas ou compiladas para tipos de evento de baixa prioridade como curtidas, enquanto mensagens diretas ou eventos relacionados à segurança podem ser enviados imediatamente. Como o e-mail é mais lento e mais caro, as preferências do usuário e o limite de taxa são especialmente importantes. A confiabilidade é alcançada através de escritas duráveis, processamento at-least-once, idempotência, retentativas e filas de dead-letter. A camada de ingestão só confirma aos produtores após o evento ser escrito de forma durável no Kafka/Pulsar. Consumidores confirmam offsets apenas após terem escrito com sucesso registros de notificação e publicado jobs de canal downstream. Como retentativas podem criar duplicatas, cada evento e notificação deve ter chaves de idempotência estáveis. Por exemplo, uma chave de notificação de curtida pode ser recipient_id + actor_id + post_id + event_type, enquanto uma chave de notificação de comentário pode incluir comment_id. O store de notificações impõe unicidade nesta chave, ou os processadores realizam escritas condicionais. Workers de entrega também devem usar IDs de tentativa e transições de estado idempotentes para que jobs duplicados não criem registros duplicados no aplicativo ou e-mails duplicados quando evitável. O sistema garante entrega at-least-once, não exactly-once, então clientes também devem deduplicar por ID de notificação. Filas de dead-letter são necessárias para mensagens venenosas, eventos malformados, falhas repetidas de provedor ou registros que não podem ser renderizados. Uma ferramenta de replay deve permitir que operadores corrijam problemas e reprocessam eventos do log durável original ou da fila de dead-letter. A retenção do Kafka deve ser longa o suficiente para suportar recuperação operacional, por exemplo, vários dias. Metadados críticos e estado de entrega também devem ser persistidos no banco de dados de notificação para auditabilidade. Para atender ao requisito de escala de 100 milhões de usuários ativos diários e 50.000 solicitações de notificação por segundo, todos os serviços principais devem ser horizontalmente escaláveis e stateless sempre que possível. APIs de ingestão escalam atrás de load balancers. Tópicos Kafka/Pulsar são particionados amplamente o suficiente para suportar throughput de pico e paralelismo de consumidores. Processadores e workers de entrega rodam em grupos de autoescalonamento ou implantações Kubernetes e escalam com base no lag da fila, CPU, latência do provedor e taxa de requisição. Bancos de dados são particionados por ID de usuário para espalhar a carga. Problemas de chave quente devem ser tratados com jobs de fanout sharded, tratamento especial para usuários celebridades e backpressure. Para fanout extremamente grande, o sistema pode usar fanout baseado em pull para notificações de baixa prioridade: em vez de escrever uma notificação por seguidor imediatamente, ele armazena o evento uma vez e o materializa quando um usuário abre o aplicativo. Isso reduz a amplificação de escrita, mas aumenta a complexidade de leitura e pode não ser apropriado para mensagens diretas ou comentários. A meta de latência de 2 segundos para 99% das notificações push e no aplicativo é atendida mantendo o caminho crítico curto: produtor para log durável, lookup de preferência do processador do cache, escrita de registro de notificação, publicação para fila de canal e entrega imediata por workers aquecidos. Workers push e no aplicativo devem ser superprovisionados para carga de pico, e as filas devem usar lanes de prioridade para que mensagens diretas e comentários sejam processados antes de curtidas de baixa prioridade. Implantação regional reduz a latência de rede. Para usuários em múltiplas regiões, o roteamento pode ser baseado na região de origem do destinatário, com replicação cross-region para recuperação de desastres. O design deve medir a latência de ponta a ponta desde a criação do evento até a aceitação do provedor ou envio do gateway, não apenas o tempo de processamento interno. Observabilidade é essencial. A plataforma deve rastrear taxa de requisição, lag de fila por partição, latência de processamento, taxa de acerto do cache de preferência, falhas de criação de notificação, taxas de erro do provedor, contagens de retentativa, volume de dead-letter, sucesso de entrega WebSocket, latência de aceitação do provedor push e latência p50/p95/p99 de ponta a ponta. Rastreamento distribuído deve carregar o ID original do evento através de cada componente. Alertas devem disparar em crescimento de lag de fila, falhas elevadas, throttling de provedor, latência de escrita de banco de dados e SLOs de latência perdidos. Existem várias trocas. Kafka ou Pulsar adicionam complexidade operacional, mas fornecem a durabilidade, replay e throughput necessários para entrega at-least-once nesta escala. Cassandra ou DynamoDB fornecem alta escalabilidade de escrita e disponibilidade, mas oferecem consulta ad hoc limitada, então análises devem ser enviadas para um data warehouse separado. Cachear preferências melhora a latência, mas introduz problemas de consistência de curta duração. Entrega at-least-once é muito mais simples e confiável do que entrega exactly-once, mas o sistema deve tolerar duplicatas usando chaves de idempotência e deduplicação do lado do cliente. Fanout-on-write oferece leituras rápidas da caixa de entrada, mas pode ser caro para eventos de alto seguidor; fanout-on-read economiza escritas, mas complica a classificação e a materialização no momento da leitura. Um modelo híbrido geralmente é o melhor: fanout-on-write para notificações diretas, importantes e de volume normal, e fanout-on-read ou fanout em lote para eventos massivos de baixa prioridade. Em resumo, o serviço deve usar uma arquitetura orientada a eventos durável com streams de mensagens particionados, processadores stateless, lookups de preferência cacheados, armazenamento persistente de notificações, filas de canal separadas, workers específicos de canal e fortes mecanismos de retentativa/idempotência. Este design escala horizontalmente para 50.000 solicitações de notificação por segundo, mantém a entrega push e no aplicativo dentro da meta p99 de 2 segundos através de caching e filas de baixa latência, e garante que as notificações não sejam perdidas persistindo eventos e registros de notificação antes de confirmar o progresso.

## Arquitetura de Serviço de Notificação Escalável ### Visão Geral do Sistema O serviço de notificação é projetado como um sistema distribuído e orientado a eventos que processa notificações de forma assíncrona para lidar com 50.000 requisições por segundo com latência inferior a 2 segundos para 99% das entregas. A arquitetura segue um padrão de microsserviços com clara separação de responsabilidades. ### Arquitetura de Alto Nível ``` Fontes de Eventos → API Gateway → Serviço de Notificação → Fila de Mensagens → Workers de Entrega ↓ Serviço de Preferências ↓ Camada de Cache (Redis) ↓ Banco de Dados (PostgreSQL) ``` ### Componentes Chave #### 1. API Gateway - **Responsabilidade:** Ponto de entrada para todas as requisições de notificação. Lida com limitação de taxa, autenticação e validação de requisições. - **Tecnologia:** NGINX ou AWS API Gateway - **Racional:** Fornece um único ponto de entrada, permite o estrangulamento de requisições para evitar sobrecarga e distribui o tráfego entre os serviços de backend. #### 2. Serviço de Notificação (Processamento Central) - **Responsabilidade:** Recebe eventos de notificação, valida-os, enriquece com preferências do usuário e publica na fila de mensagens. - **Tecnologia:** Microsserviço sem estado (Node.js, Go ou Java) - **Principais Recursos:** - Valida o payload da notificação - Busca preferências do usuário no cache - Determina os canais de notificação (push, in-app, e-mail) com base nas configurações do usuário - Publica notificações enriquecidas na fila de mensagens - **Escalabilidade:** Escalável horizontalmente; múltiplas instâncias atrás de um balanceador de carga #### 3. Fila de Mensagens (Barramento de Eventos) - **Tecnologia:** Apache Kafka ou AWS SQS/SNS - **Racional:** - Desacopla a geração de notificações da entrega - Fornece durabilidade e capacidade de repetição para garantia de entrega pelo menos uma vez - Permite o processamento paralelo de notificações - Lida com picos de tráfego armazenando requisições em buffer - **Configuração:** Múltiplas partições (por exemplo, 100-200) para permitir o consumo paralelo - **Estrutura de Tópicos:** Tópicos separados para notificações push, in-app e e-mail para permitir escalabilidade independente #### 4. Serviço de Preferências - **Responsabilidade:** Gerencia as preferências e configurações de notificação do usuário. - **Tecnologia:** Microsserviço com backend PostgreSQL - **Recursos:** - Armazena preferências do usuário (tipos de notificação, canais, limites de frequência) - Fornece API para os usuários atualizarem preferências - Armazena preferências em cache no Redis para acesso rápido - **Escalabilidade:** Serviço com muitas leituras; o cache reduz significativamente a carga do banco de dados #### 5. Camada de Cache - **Tecnologia:** Cluster Redis - **Propósito:** - Armazena em cache preferências do usuário (TTL: 1 hora) - Armazena em cache tokens de dispositivo do usuário para notificações push - Armazena contadores de limitação de taxa - Reduz as consultas ao banco de dados em mais de 90% - **Racional:** Latência inferior a um milissegundo para consultas de preferência #### 6. Workers de Entrega - **Worker de Notificação Push:** - Consome do tópico push - Integra-se com FCM (Firebase Cloud Messaging) e APNs (Apple Push Notification service) - Lida com o gerenciamento de tokens de dispositivo e limpeza de tokens inválidos - Implementa backoff exponencial para retentativas - **Worker de Notificação In-App:** - Consome do tópico in-app - Armazena notificações em um banco de dados de séries temporais (por exemplo, Cassandra ou ClickHouse) - Publica em servidores WebSocket para entrega em tempo real - Mantém o status de notificação como lida/não lida - **Worker de Notificação por E-mail:** - Consome do tópico de e-mail - Agrupa e-mails para eficiência - Integra-se com serviço de e-mail (SendGrid, AWS SES) - Implementa limitação de taxa para evitar filtros de spam #### 7. Servidor WebSocket - **Responsabilidade:** Mantém conexões persistentes com clientes móveis e web para notificações in-app em tempo real. - **Tecnologia:** Node.js com Socket.io ou Go com gorilla/websocket - **Escalabilidade:** Servidores sem estado; usa pub/sub do Redis para comunicação entre servidores - **Fallback:** Long-polling HTTP para clientes que não suportam WebSocket #### 8. Armazenamento de Notificações (Banco de Dados de Séries Temporais) - **Tecnologia:** Cassandra ou ClickHouse - **Propósito:** Armazena todas as notificações para auditoria, análise e histórico de notificações do usuário - **Racional:** Otimizado para cargas de trabalho com muitas escritas e consultas por intervalo de tempo - **Retenção:** 90 dias de histórico de notificações #### 9. Registro de Dispositivos do Usuário - **Tecnologia:** Redis + PostgreSQL - **Propósito:** Mantém o mapeamento de usuários para seus dispositivos e tokens push - **Recursos:** - Rastreia o registro/desregistro de dispositivos - Armazena metadados do dispositivo (SO, versão do aplicativo) - Lida com a atualização e invalidação de tokens ### Fluxo de Dados 1. **Ingestão de Eventos:** Fontes de eventos (ações do usuário, eventos do sistema) enviam requisições de notificação para o API Gateway 2. **Validação e Enriquecimento:** Serviço de Notificação valida o payload e busca preferências do usuário no cache 3. **Determinação de Canal:** Com base nas preferências, a notificação é roteada para o tópico apropriado (push, in-app, e-mail) 4. **Enfileiramento:** Fila de Mensagens armazena notificações em buffer e garante durabilidade 5. **Entrega:** Workers especializados consomem dos tópicos e entregam pelos canais respectivos 6. **Confirmação:** Workers de entrega confirmam a entrega bem-sucedida e atualizam o status da notificação ### Atendendo aos Requisitos #### Escalabilidade (50.000 req/seg) - **Escalabilidade Horizontal:** Todos os componentes são sem estado e escaláveis horizontalmente - **Particionamento da Fila de Mensagens:** Tópicos Kafka particionados entre múltiplos brokers; cada partição pode lidar com ~500-1000 req/seg - **Fragmentação do Banco de Dados:** Dados do usuário fragmentados por user_id para distribuir a carga - **Estratégia de Cache:** Redis armazena em cache dados quentes, reduzindo as consultas ao banco de dados em mais de 90% - **Balanceamento de Carga:** API Gateway distribui o tráfego entre as instâncias do Serviço de Notificação #### Baixa Latência (99% em até 2 segundos) - **Processamento Assíncrono:** Notificações processadas de forma assíncrona; API retorna imediatamente após o enfileiramento - **Cache:** Preferências do usuário armazenadas em cache no Redis (acesso inferior a um milissegundo) - **Integração Direta:** Workers push integram-se diretamente com FCM/APNs sem saltos intermediários - **WebSocket para In-App:** Entrega em tempo real via conexões persistentes - **Otimização:** Processamento em lote para notificações por e-mail (aceitável para o caso de uso de e-mail) - **Monitoramento:** Latência rastreada por componente; alertas para degradação #### Confiabilidade (Entrega Pelo Menos Uma Vez) - **Durabilidade da Fila de Mensagens:** Kafka replica mensagens entre brokers (fator de replicação: 3) - **Filas Persistentes:** Mensagens persistidas em disco antes da confirmação - **Idempotência:** Notificações incluem IDs exclusivos; workers implementam processamento idempotente - **Lógica de Retentativa:** Entregas falhadas são retentadas com backoff exponencial (máximo de 5 retentativas em 24 horas) - **Fila de Mensagens Mortas (Dead Letter Queue - DLQ):** Notificações falhadas após retentativas máximas movidas para DLQ para investigação manual - **Monitoramento e Alertas:** Dashboards em tempo real rastreiam taxas de sucesso de entrega; alertas para falhas - **Backup e Recuperação:** Backups regulares de dados de preferência e notificação; procedimentos de recuperação de desastres #### Personalização - **Serviço de Preferências:** Serviço dedicado gerencia configurações de notificação do usuário - **Controles Granulares:** Usuários podem desativar notificações por tipo (curtidas, comentários, follows) e por canal - **Limites de Frequência:** Suporte para opções de resumo diário/semanal - **Horário de Silêncio:** Usuários podem definir horário de silêncio (por exemplo, sem notificações push das 22h às 8h) - **Invalidação de Cache:** Mudanças de preferência invalidam o cache imediatamente para efeito em tempo real ### Escolhas de Tecnologia e Compromissos | Componente | Tecnologia | Racional | Compromissos | |-----------|-----------|-----------|-----------| | Fila de Mensagens | Kafka | Alta taxa de transferência, durabilidade, capacidade de repetição | Complexidade operacional, requer gerenciamento de cluster | | Cache | Cluster Redis | Latência inferior a um milissegundo, suporta estruturas de dados complexas | Limitado por memória, requer políticas de evicção cuidadosas | | DB de Preferências | PostgreSQL | Conformidade ACID, consultas complexas, ecossistema maduro | Limites de escalabilidade vertical; requer réplicas de leitura | | Armazenamento de Notificações | Cassandra | Otimizado para escrita, distribuído, lida com dados de séries temporais | Consistência eventual, modelo operacional complexo | | Integração Push | FCM/APNs | Padrão da indústria, alta confiabilidade | Bloqueio de fornecedor, limites de taxa por provedor | | WebSocket | Socket.io/gorilla | Comunicação em tempo real, suporte a fallback | Sobrecarga de memória por conexão, requer sessões fixas | ### Considerações Operacionais #### Monitoramento e Observabilidade - **Métricas:** Taxa de transferência de notificações, percentis de latência (p50, p95, p99), taxa de sucesso de entrega - **Logs:** Logging estruturado com IDs de correlação para rastreamento de ponta a ponta - **Rastreamento Distribuído:** Jaeger ou Zipkin para visualização do fluxo de requisições - **Alertas:** Integração com PagerDuty para falhas críticas #### Implantação e Escalabilidade - **Containerização:** Contêineres Docker para todos os serviços - **Orquestração:** Kubernetes para escalabilidade e implantação automatizadas - **Auto-escalabilidade:** Horizontal Pod Autoscaler baseado em CPU/memória e profundidade da fila - **Implantação Blue-Green:** Implantações sem tempo de inatividade para atualizações de serviço #### Otimização de Custos - **Capacidade Reservada:** Brokers Kafka e instâncias de banco de dados em instâncias reservadas - **Armazenamento em Camadas:** Dados quentes em Redis, dados mornos em PostgreSQL, dados frios em S3 - **Processamento em Lote:** Notificações por e-mail agrupadas para reduzir chamadas de API - **Limites de Recursos:** Limites de taxa por usuário para evitar esgotamento de recursos ### Gargalos Potenciais e Mitigação 1. **Gargalo do Banco de Dados:** Consultas de preferência - Mitigação: Cache Redis com TTL de 1 hora; réplicas de leitura para PostgreSQL 2. **Gargalo da Fila de Mensagens:** Taxa de transferência do Kafka - Mitigação: Aumentar a contagem de partições; atualizar hardware do broker; usar compressão 3. **Limites de Taxa do Serviço Push:** Limites do FCM/APNs - Mitigação: Implementar enfileiramento de requisições; agrupar requisições; usar múltiplas contas de serviço 4. **Limites de Conexão WebSocket:** Limites de conexão por servidor - Mitigação: Escalabilidade horizontal; pool de conexões; balanceamento de carga entre servidores ### Conclusão Esta arquitetura fornece um serviço de notificação escalável, confiável e de baixa latência, capaz de lidar com 50.000 requisições por segundo, mantendo entrega inferior a 2 segundos para 99% das notificações. O uso de processamento assíncrono, filas de mensagens e cache garante desempenho e confiabilidade. O design modular permite a escalabilidade independente dos componentes com base na demanda, e o monitoramento abrangente garante visibilidade operacional. O sistema lida graciosamente com falhas por meio de lógica de retentativa, filas de mensagens mortas e redundância, garantindo semântica de entrega pelo menos uma vez.