Projetar um Sistema de Notificações em Tempo Real para E-commerce

Visão Geral Proponho uma plataforma de notificação escalável horizontalmente e focada em streaming, construída a partir de microsserviços desacoplados e serviços de nuvem gerenciados. Ideias centrais: usar um log de eventos durável para ingestão e repetição (Kafka/Kinesis/Pub/Sub), processadores de stream para enriquecer e personalizar eventos, um pipeline de entrega que persiste o estado de entrega e retenta para garantias de "pelo menos uma vez", e conectores específicos do dispositivo para push (APNs/FCM) e web em tempo real (WebSocket). O design atende a picos de 100 mil notificações/min (≈1,7 mil/seg), visa entrega em menos de 5 segundos para 99% das mensagens e suporta personalização e entrega confiável. Arquitetura de alto nível (componentes e interações) 1) Produtores de Eventos - Fontes: Serviço de Pedidos (atualizações de pedidos), Serviço de Preços (alterações de preços), Marketing/CRM (promoções relâmpago). Cada serviço emite eventos leves para a camada de ingestão sempre que ocorre uma alteração relevante. Os eventos incluem event_id, event_type, payload, timestamp e metadados (user_ids ou product_ids). 2) Ingestão / Log de Eventos Durável - Log particionado gerenciado: Apache Kafka (auto-gerenciado ou Confluent Cloud) ou equivalentes em nuvem (AWS Kinesis Data Streams, GCP Pub/Sub). Os produtores publicam eventos em tópicos organizados por tipo de evento e chave de partição (user_id ou product_id) para preservar a ordem onde for necessário (por exemplo, atualizações de pedidos por pedido). - Por que log durável: fornece repetibilidade, retenção para retentativas e suavização de backpressure. 3) Processamento de Stream / Camada de Enriquecimento - Processadores de stream sem estado/com estado (Apache Flink, Kafka Streams ou Dataflow gerenciado) assinam tópicos de eventos para: validar eventos, enriquecer com perfil e preferências do usuário, juntar com dados de produto/segmento e decidir a elegibilidade e prioridade da notificação (por exemplo, atualização crítica de pedido vs. marketing). - Saída: Tarefas de Notificação normalizadas (task_id, user_id(s), payload, type, priority, ttl, dedup_key) publicadas em um tópico de Tarefa de Notificação. 4) Personalização e Segmentação - Regras de personalização residem em um serviço que combina: feature store / banco de dados de perfil (DynamoDB/Cassandra/Postgres + cache Redis para leituras rápidas) e um motor de regras ou modelo de ML. Processadores de stream chamam este serviço ou usam consultas de cache local para determinar destinatários e variantes de conteúdo direcionados. - Para eventos de segmentação amplos (promoções relâmpago para um segmento), use segmentos pré-calculados armazenados em um armazenamento rápido (Redis, Druid ou consulta BigQuery/ElastiCache) para expandir para listas de usuários ou para aplicar lógica de filtro dentro dos trabalhos de streaming. 5) Orquestração de Entrega / Fan-out - Um serviço de Orquestração de Entrega assina o tópico de Tarefa de Notificação, avalia registros de dispositivos, regras de throttling e estratégia de fan-out. Para notificações de usuário único (atualização de pedido), ele cria um trabalho de entrega por dispositivo; para transmissão baseada em segmento, ele se expande para muitos trabalhos de entrega através de uma fila particionada. - Trabalhos de entrega são colocados em filas de entrega persistentes por shard (tópicos Kafka, Redis Streams ou SQS com FIFO para ordenação onde necessário). Os trabalhos incluem contadores de retentativa e chaves de idempotência/deduplicação. 6) Trabalhadores de Entrega / Conectores - Frota de trabalhadores sem estado escalada automaticamente pelo atraso da fila. Cada trabalhador puxa trabalhos, tenta a entrega através do conector apropriado para o canal do dispositivo: - Push móvel: FCM (Android) e APNs (iOS) usando tokens de dispositivo armazenados no Registro de Dispositivos. - Web/Navegador: Web Push (VAPID) ou conexões WebSocket persistentes (gerenciadas através de um serviço de conexão como AWS API Gateway WebSocket ou clusters de socket auto-gerenciados atrás de ELB). - Canais de fallback: E-mail (SES/SendGrid) ou SMS (Twilio) para notificações críticas não entregues. - Os trabalhadores persistem tentativas de entrega (sucesso/falha) em um armazenamento de Status de Entrega e emitem eventos de conclusão ou retentativa para o log para monitoramento e retentativas adicionais. 7) Registro de Dispositivos e Preferências do Usuário - Armazenamento durável de user_id -> dispositivos (token, plataforma, last_seen, preferências, flags de opt-in). Use DynamoDB/Cassandra para alta taxa de transferência de gravação; cache de dispositivos ativos em Redis para consultas de baixa latência. 8) Estado de Entrega e Repetibilidade - Todas as tarefas de notificação e tentativas de entrega são registradas em armazenamentos duráveis (Kafka + arquivamento para S3) e um banco de dados de Status de Entrega. Isso permite entrega "pelo menos uma vez", auditoria e reconciliação. Entregas não confirmadas/falhadas são retentadas por um orquestrador de retentativas com backoff exponencial. 9) Monitoramento, Observabilidade e Aplicação de SLA - Métricas: taxa de ingestão, latência de processamento, atraso da fila, taxa de sucesso de entrega. Rastreamentos para latência por caminho (OpenTelemetry) e alertas para violações de SLA. Dashboards para monitorar latência p99 e taxas de falha por canal. Principais escolhas de design e justificativas - Log de eventos durável (Kafka/Kinesis/PubSub): fornece alta taxa de transferência e repetibilidade, o que é essencial para semântica "pelo menos uma vez" e depuração. O particionamento por user_id/product_id preserva a ordem por entidade (crítico para atualizações de pedidos). Streaming gerenciado em nuvem reduz a sobrecarga operacional. - Processamento de stream (Flink/Kafka Streams/Dataflow): permite enriquecimento e segmentação em sub-segundos perto da ingestão. O processamento de stream com estado suporta junções em janelas (por exemplo, combinar eventos de queda de preço com listas de desejos) com baixa latência. - Registro de Dispositivos em NoSQL + cache: DynamoDB/Cassandra escala horizontalmente para dezenas de milhões de usuários; Redis lida com consultas de caminho quente para decisões de baixa latência. - Filas de entrega e trabalhadores escalados automaticamente: desacopla o fan-out pesado do processamento upstream, permitindo escalabilidade graciosa durante promoções relâmpago, controlando os limites de taxa dos provedores de push downstream. - Conectores de push (APNs/FCM) + WebSockets: serviços de push minimizam a sondagem do cliente e alcançam baixa latência. WebSockets são usados para entrega em tempo real no aplicativo/web; se o WebSocket não estiver disponível, recorra a push ou pull. - "Pelo menos uma vez", idempotência e deduplicação: armazene a chave de dedup em nível de tarefa e torne a entrega idempotente no cliente ou use confirmações de SDK sempre que possível. No lado do servidor, deduplique por task_id/dedup_key antes de criar notificações visíveis para o usuário. Atendendo aos requisitos - Alta Taxa de Transferência: O log particionado e os trabalhadores escalados automaticamente suportam escalabilidade horizontal; Kafka/Kinesis podem lidar com milhões de eventos/segundo com múltiplas partições. 100 mil/min é modesto para tais sistemas; a arquitetura pode escalar para volumes muito maiores adicionando partições e trabalhadores. - Baixa Latência: O enriquecimento em stream e os conectores diretos de push/WebSocket são caminhos de baixa latência. Visando <5s p99: mantenha o pipeline de processamento abaixo de 1-2s (trabalhos de stream), baixo atraso da fila de entrega através de trabalhadores escalados automaticamente e use caches de dispositivo para evitar consultas ao banco de dados no caminho quente. - Confiabilidade: Log de eventos durável + estados de entrega persistidos + orquestrador de retentativas garantem entrega "pelo menos uma vez". Para notificações críticas (atualizações de pedidos), habilite garantias mais fortes: confirmação síncrona dos serviços downstream e armazenamento de um recibo de entrega confirmado (por exemplo, confirmação de dispositivo ou confirmação de canal de fallback). Use backoff exponencial e escalonamento para canais alternativos. - Escalabilidade: Todas as peças com estado usam armazenamentos escaláveis horizontalmente (Kafka, DynamoDB/Cassandra, clusters Redis). Trabalhadores e processadores de stream são contêineres sem estado que escalam automaticamente. Use particionamento e sharding para crescimento. - Personalização: Junções em tempo real em processadores de stream mais armazenamento de perfil em cache permitem personalização por usuário. Segmentos pré-calculados aceleram grandes fan-outs (promoções relâmpago) evitando avaliação por usuário em tempo real. Trade-offs (Consistência, Disponibilidade, Custo) - Consistência vs Disponibilidade: Favorecemos a disponibilidade e a consistência eventual para notificações de marketing (aceitável se uma promoção chegar ligeiramente fora de ordem). Para eventos críticos de pedidos, usamos ordenação e persistência mais fortes (particionamento e persistência síncrona) para garantir a ordem correta e a entrega confiável. Essa abordagem híbrida equilibra a experiência do usuário e a resiliência do sistema. - "Pelo menos uma vez" vs "Exatamente uma vez": Alcançar "exatamente uma vez" em todo o pipeline adiciona complexidade e custo (Kafka transacional, two-phase commit ou idempotência de ponta a ponta). Escolhemos "pelo menos uma vez" com manipuladores idempotentes e chaves de dedup para evitar notificações duplicadas visíveis, mantendo o sistema mais simples e escalável. - Serviços gerenciados vs auto-hospedados: Streaming gerenciado (Kinesis/PubSub) e infraestrutura de push reduzem o fardo operacional e aumentam a disponibilidade, mas custam mais. Para velocidade de chegada ao mercado e confiabilidade em escala, serviços gerenciados são recomendados. Se o custo se tornar dominante, considere Kafka auto-hospedado com automação robusta. Considerações operacionais - Limitação de taxa / Throttling: Quotas por usuário e por provedor para evitar sobrecarga e rejeições de limite de taxa do provedor. - Backfill e repetição: Use o log durável para repetir notificações perdidas (por exemplo, após uma interrupção) e para reconstruir o status de entrega. - Testes: Testes de caos para falhas de partições e provedores, testes de carga para validar latência p99 sob pico. - Segurança e privacidade: Criptografe tokens em repouso, rotacione credenciais de push, respeite opt-outs e controles de PII. SLA e KPIs para monitorar - Taxa de transferência (eventos/min), latência de processamento de stream (p50/p90/p99), latência de entrega de ponta a ponta (p50/p90/p99), taxa de sucesso de entrega por canal, taxa de retentativa, atraso da fila e atraso do grupo de consumidores. Resumo Este design usa um log de eventos durável e particionado mais processamento de stream para enriquecimento/personalização, um pipeline de entrega persistente com trabalhadores escalados automaticamente para fan-out e conectores específicos de canal (APNs/FCM/WebSocket) para entrega rápida. Prioriza disponibilidade e repetibilidade para atender à entrega "pelo menos uma vez", usa cache e particionamento para atender a baixa latência e alta taxa de transferência, e confia em componentes de nuvem gerenciados para reduzir o fardo operacional, permitindo escalabilidade horizontal para suportar o crescimento futuro.

Projeto de um Sistema de Notificações de E-commerce em Tempo Real Visão Geral O sistema proposto é uma arquitetura orientada a eventos e baseada em microsserviços que ingere eventos de múltiplos serviços upstream, processa e roteia-os através de um message broker, e entrega notificações a 50 milhões de usuários em canais móveis e web com garantias de entrega pelo menos uma vez, latência inferior a 5 segundos no percentil 99, e a capacidade de sustentar 100.000 notificações por minuto durante eventos de pico. O projeto assume uma implantação cloud-native na AWS, embora os princípios se traduzam diretamente para equivalentes GCP ou Azure. Arquitetura de Alto Nível A arquitetura consiste em seis camadas lógicas: Produtores de Eventos, Ingestão de Eventos, Processamento e Roteamento, Preferências e Segmentação do Usuário, Entrega e Observabilidade. 1. Produtores de Eventos Múltiplos serviços upstream geram eventos que disparam notificações. Estes incluem o Serviço de Pedidos (emitindo eventos de pedido-realizado, enviado, em-trânsito, entregue), o Serviço de Preços (emitindo eventos de queda-de-preço quando o preço de um item observado cai abaixo de um limite) e o Serviço de Campanhas (emitindo eventos de início-de-promoção-relâmpago criados pela equipe de marketing). Cada produtor publica um envelope de evento estruturado contendo um tipo de evento, um timestamp, um payload e uma chave de idempotência para uma camada central de ingestão. Os produtores usam uma chamada de publicação assíncrona, fire-and-forget, para que sua própria latência não seja afetada. 2. Camada de Ingestão de Eventos — Apache Kafka Todos os eventos fluem para o Apache Kafka (Amazon MSK na AWS). O Kafka é escolhido por várias razões. Primeiro, ele fornece logs duráveis e somente anexáveis com replicação configurável (fator de replicação de 3, min.insync.replicas de 2), o que significa que uma escrita confirmada sobrevive à perda de qualquer broker único, apoiando diretamente o requisito de confiabilidade. Segundo, o modelo de tópicos particionados do Kafka permite escalabilidade horizontal: particionamos o tópico de eventos-de-pedido por ID de usuário para que todos os eventos de um determinado usuário sejam processados em ordem, enquanto o tópico geral pode ser distribuído por dezenas de partições para absorver o pico de vazão. Com 100.000 notificações por minuto, a taxa média é de aproximadamente 1.667 eventos por segundo, bem dentro da capacidade de um cluster Kafka modesto, mas o particionamento nos permite escalar para 10x ou mais sem alteração arquitetural. Terceiro, o Kafka desacopla produtores de consumidores, de modo que uma lentidão temporária na camada de entrega não cause back-pressure no serviço de pedidos. Design de tópicos: tópicos separados para eventos-de-pedido, eventos-de-preço e eventos-de-campanha. Isso permite grupos de consumidores independentes com políticas de escalonamento e retentativa diferentes. Trade-off considerado: Avaliamos Amazon SQS mais SNS como uma alternativa gerenciada mais simples. O SQS satisfaria a entrega pelo menos uma vez e é operacionalmente mais leve, mas carece das garantias de ordenação do Kafka por partição e de sua capacidade de replay, que é valiosa para reprocessamento após um bug. O custo operacional adicional do Kafka é justificado pelos benefícios de ordenação e replay em nossa escala. 3. Camada de Processamento e Roteamento — Serviço de Notificações Um microsserviço escalado horizontalmente, o Serviço de Notificações, consome de tópicos Kafka. Ele realiza várias tarefas. Primeiro, ele resolve o público-alvo. Para eventos de pedido, o alvo é um único usuário (extraído do payload). Para eventos de queda de preço, ele consulta o Serviço de Lista de Desejos ou uma visão materializada pré-computada para encontrar todos os usuários que observam aquele item. Para eventos de promoção relâmpago, ele consulta o Serviço de Segmentação para resolver um segmento de usuário. Segundo, ele enriquece a notificação buscando o nome de exibição do usuário, a URL da imagem do produto e o template de mensagem localizado de um Serviço de Template suportado por um cache Redis sobre um store PostgreSQL. Terceiro, ele aplica as preferências do usuário. Cada usuário tem um documento de preferência (armazenado no DynamoDB para acesso chave-valor de baixa latência) especificando canais optados (push, e-mail, SMS, in-app), horários de silêncio e interesses de categoria. O serviço filtra e respeita essas preferências, o que apoia diretamente o requisito de personalização. Quarto, ele distribui tarefas de entrega. Para cada par usuário-canal resolvido, o serviço produz uma mensagem de entrega em um tópico Kafka por canal (entrega-push, entrega-email, entrega-sms, entrega-in-app). Esta etapa de distribuição é crítica: ela converte um evento lógico em potencialmente milhões de tarefas de entrega individuais (para uma promoção relâmpago visando todos os usuários), e o Kafka absorve esse burst. Escalonamento: O Serviço de Notificações é executado como um Deployment Kubernetes (Amazon EKS) com um Horizontal Pod Autoscaler baseado no lag do consumidor Kafka. Durante uma promoção relâmpago, o lag do consumidor aumenta e pods adicionais são iniciados em segundos. Idempotência: Cada mensagem de entrega carrega a chave de idempotência do evento original combinada com o ID do usuário. Os workers de entrega downstream usam essa chave composta para deduplicar, garantindo que, embora o Kafka forneça semântica de pelo menos uma vez, os usuários não recebam notificações duplicadas. 4. Preferências e Segmentação do Usuário As preferências do usuário são armazenadas no Amazon DynamoDB, particionadas por ID de usuário. O DynamoDB é escolhido por sua latência de leitura de um único dígito de milissegundos e escalabilidade horizontal contínua, o que é importante porque cada notificação individual requer uma consulta de preferência. Um cache DAX (DynamoDB Accelerator) fica na frente para chaves quentes. Para segmentação (visando usuários interessados em uma categoria ou usuários em uma região geográfica), mantemos listas de associação de segmentos pré-computadas. Um job batch noturno (Apache Spark no EMR) e um processador de stream em tempo real (Kafka Streams ou Flink) mantêm essas listas atualizadas em uma tabela DynamoDB separada com chave por ID de segmento, com o valor sendo uma lista de IDs de usuário armazenados no S3 para segmentos muito grandes. Quando o Serviço de Campanhas cria uma promoção relâmpago visando o segmento de eletrônicos, o Serviço de Notificações lê a associação do segmento e itera sobre ela, produzindo tarefas de entrega em lotes. Trade-off: Pré-computar segmentos troca armazenamento e staleness (um usuário que mudou suas preferências há uma hora pode ainda estar no segmento antigo) por velocidade de consulta. A avaliação de segmento em tempo real no momento da entrega seria mais precisa, mas exigiria a varredura de milhões de registros de usuários sob pressão de tempo, violando o requisito de latência. A abordagem híbrida (batch noturno mais atualizações de stream em tempo real) mantém os segmentos atualizados em minutos. 5. Camada de Entrega Grupos de consumidores separados lidam com cada canal. Notificações Push (Mobile): Workers consomem do tópico de entrega-push e chamam o Firebase Cloud Messaging (FCM) para Android e o Apple Push Notification Service (APNS) para iOS. Usamos o FCM como gateway unificado para ambas as plataformas sempre que possível. Os workers agrupam chamadas para a API HTTP v1 do FCM (até 500 mensagens por chamada de lote) para maximizar a vazão. Entregas falhas (tokens inválidos, limites de taxa) são retentadas com backoff exponencial. Tokens permanentemente falhos (dispositivos não registrados) disparam um evento assíncrono para purgar o token do Registro de Dispositivos do Usuário. Web Push: Workers enviam mensagens do Protocolo Web Push usando o padrão VAPID. A assinatura de push do usuário (URL do endpoint e chaves) é armazenada no Registro de Dispositivos do Usuário (DynamoDB). Este canal reutiliza o mesmo tópico de entrega-push com um campo de subtipo de canal. Notificações In-App: Para usuários que estão atualmente online, mantemos conexões WebSocket persistentes através de uma API WebSocket do API Gateway (AWS API Gateway WebSocket ou um serviço autogerenciado usando Socket.IO no EKS). Um Registro de Conexões (Redis Cluster) mapeia IDs de usuário para IDs de conexão WebSocket. O worker de entrega in-app consulta a conexão e, se o usuário estiver conectado, envia a notificação em tempo real. Se não estiver conectado, a notificação é gravada em uma Caixa de Entrada In-App (tabela DynamoDB particionada por ID de usuário, ordenada por timestamp) e entregue quando o usuário abrir o aplicativo. Essa gravação dupla garante que nenhuma notificação seja perdida, mesmo que o usuário esteja offline. E-mail e SMS: Canais de menor prioridade. Workers consomem dos tópicos de entrega-email e entrega-sms e chamam Amazon SES e Amazon SNS (SMS) respectivamente. Esses canais têm latência aceitável mais alta (30 segundos a minutos), portanto, podem ser escalados de forma mais conservadora. Garantias de Entrega: A entrega pelo menos uma vez é alcançada de ponta a ponta. Os consumidores Kafka confirmam os offsets somente após a API de entrega downstream confirmar o recebimento (ou a mensagem ser persistida na caixa de entrada in-app). Se um worker falhar antes de confirmar, a mensagem é redelivrada. A chave de idempotência em cada estágio evita duplicatas visíveis para o usuário. 6. Rastreamento de Status de Notificação Um Serviço de Status leve registra o ciclo de vida de cada notificação: criada, enviada, entregue, lida. Recibos de entrega do FCM/APNS e recibos de leitura do aplicativo cliente são ingeridos via um tópico Kafka e gravados em um store de séries temporais (Amazon Timestream ou ClickHouse) para análise, e no DynamoDB para consultas de status por usuário (para que o aplicativo possa mostrar indicadores de lido/não lido). Esses dados também alimentam a lógica de retentativa: se uma notificação push não for confirmada como entregue em 30 segundos, o sistema pode recorrer ao e-mail. 7. Observabilidade Prometheus e Grafana monitoram o lag do consumidor Kafka, percentis de latência de entrega, taxas de erro por canal e vazão. Alertas são disparados se a latência de entrega p99 exceder 4 segundos (dando um buffer de 1 segundo antes do SLA de 5 segundos). Rastreamento distribuído (OpenTelemetry com Jaeger) rastreia um evento do produtor até a entrega, permitindo depuração rápida. Logs estruturados são enviados para o Amazon OpenSearch para busca e auditoria. Atendendo aos Requisitos Alta Vazão: Tópicos particionados do Kafka e grupos de consumidores escalados horizontalmente lidam com 100K notificações por minuto confortavelmente. A distribuição para campanhas grandes é absorvida pelo buffer do Kafka, e os workers de entrega escalam automaticamente com base no lag. Baixa Latência: O caminho crítico para uma notificação de usuário único (por exemplo, pedido enviado) é: produtor publica no Kafka (menos de 50ms), Serviço de Notificações consome e enriquece (menos de 100ms incluindo consultas DynamoDB e Redis), worker de entrega envia para FCM/APNS (menos de 500ms típico). Total bem abaixo de 5 segundos. Para campanhas de grande distribuição, o sistema paraleliza entre muitos workers de entrega; o particionamento do Kafka garante que nenhum worker único seja um gargalo. Confiabilidade: Replicação do Kafka, gerenciamento de offsets do consumidor e entrega idempotente garantem semântica de pelo menos uma vez. Uma fila de mensagens mortas (DLQ) captura mensagens que falham após um número configurável de retentativas, e uma equipe de operações é alertada para investigar. Notificações de pedido críticas são marcadas com um campo de prioridade e roteadas para uma partição de alta prioridade dedicada com seu próprio grupo de consumidores, garantindo que nunca sejam starved por uma enxurrada de notificações promocionais. Escalabilidade: Cada componente escala horizontalmente. As partições do Kafka podem ser aumentadas. Os pods Kubernetes escalam automaticamente. O DynamoDB escala sob demanda. Não há pontos únicos de falha ou gargalos de thread único. Personalização: Preferências do usuário no DynamoDB controlam a seleção de canal e os horários de silêncio. Segmentos pré-computados permitem campanhas direcionadas. O Serviço de Template suporta templates de mensagem por localidade, por categoria, e variantes de teste A/B podem ser selecionadas no momento do enriquecimento. Principais Trade-offs e Justificativas Consistência vs. Disponibilidade: O sistema favorece a disponibilidade (AP no termo CAP). Se o store de preferências estiver momentaneamente inacessível, o Serviço de Notificações usa uma preferência em cache ou padrão em vez de bloquear. Isso significa que um usuário pode ocasionalmente receber uma notificação em um canal do qual acabou de sair, mas nenhuma notificação é perdida ou atrasada. Para um sistema de notificações de e-commerce, disponibilidade e baixa latência são mais valiosas do que consistência estrita de preferências. Pelo Menos Uma Vez vs. Exatamente Uma Vez: Entrega exatamente uma vez real através de sistemas externos (FCM, APNS) é impraticável. Em vez disso, garantimos pelo menos uma vez e usamos chaves de idempotência para suprimir duplicatas no nível da aplicação. Isso é mais simples, mais barato e suficiente. Serviços Gerenciados vs. Auto-hospedado: Usamos Kafka gerenciado (MSK), Kubernetes gerenciado (EKS) e bancos de dados gerenciados (DynamoDB) para reduzir o fardo operacional. O trade-off é um custo por unidade mais alto em comparação com auto-hospedado, mas o tempo de engenharia economizado e a confiabilidade dos serviços gerenciados justificam isso em nossa escala. Push vs. Pull para In-App: WebSockets (push) fornecem a menor latência para usuários online, mas exigem a manutenção de conexões persistentes e um registro de conexões. O polling seria mais simples, mas adicionaria segundos de latência e geraria carga desnecessária. A abordagem híbrida (WebSocket quando online, caixa de entrada quando offline) equilibra latência e uso de recursos. Considerações de Custo: Os maiores impulsionadores de custo são a vazão do Kafka (preços do MSK), a capacidade de leitura do DynamoDB para consultas de preferência e as chamadas de API FCM/APNS (gratuitas para FCM, mas a infraestrutura para chamá-las em escala não é). Para controlar os custos, agrupamos chamadas FCM, usamos preços sob demanda do DynamoDB (que é econômico para cargas de trabalho esporádicas) e usamos instâncias spot para workers de entrega não críticos (e-mail, SMS). Conclusão Esta arquitetura fornece um sistema de notificações robusto, escalável e de baixa latência, adequado para uma plataforma de e-commerce de 50 milhões de usuários. Ao alavancar o Kafka como o sistema nervoso central, o DynamoDB para acesso rápido a dados do usuário e workers de entrega específicos do canal que escalam independentemente, o sistema atende a todos os requisitos declarados, permanecendo operacionalmente gerenciável e econômico. O projeto é extensível: adicionar um novo canal de notificação (por exemplo, WhatsApp) requer apenas um novo worker de entrega consumindo de um novo tópico Kafka, sem alterações nos produtores de eventos upstream ou na lógica de processamento principal.