Projetar um Sistema de Notificações em Tempo Real para um Aplicativo de Ride-Sharing

Arquitetura de alto nível (componentes e interações) 1) Produtores de eventos (serviços de origem) - Serviço de Viagem: emite eventos do ciclo de vida da viagem (motorista_atribuído, viagem_concluída). - Serviço de Despacho/Correspondência: emite eventos de motorista_atribuído e quaisquer eventos de reatribuição. - Serviço de ETA/Localização: calcula continuamente o ETA a partir de fluxos de GPS do motorista; emite motorista_chegando_em_breve quando o limite de ETA (por exemplo, <=2 minutos) é cruzado com histerese. - Serviço de Promoções: cria eventos de campanha com regras de geolocalização e definições de público. 2) Ingestão de Notificações + Barramento de Eventos - Todos os serviços publicam eventos de domínio em um barramento de eventos durável. - Os eventos são padronizados (user_id, ride_id, event_type, timestamp, payload, idempotency_key, priority, locale). 3) Orquestrador de Notificações (regras + roteamento) - Consome eventos do barramento. - Aplica regras de negócios (quem notificar: passageiro, motorista; horários de silêncio; opt-outs do usuário; limites de taxa; não perturbe; canais de fallback). - Enriquece notificações (busca nome/veículo do motorista, link do recibo, texto do ETA) por meio de leituras em cache. - Produz “jobs de notificação” para filas específicas do canal com prioridade (transacional > promocional). 4) Serviço de Usuário/Dispositivo e Preferências - Armazena tokens de dispositivo (APNs/FCM), plataforma, versão do aplicativo, último acesso, idioma e preferências de notificação. - Expõe consulta de baixa latência (cache primeiro). 5) Workers de Entrega (adaptadores de canal) - Gateway de Push: envia para APNs da Apple e FCM do Google. - Gateway SMS (fallback opcional para mensagens críticas): Twilio ou agregador direto. - Gateway In-app/WebSocket (opcional): para usuários atualmente ativos no aplicativo. 6) Rastreamento de Entrega + Retentativa + DLQ - Tentativas de entrega registradas (enviado, aceito pelo provedor, falhou com motivo). - Retentativas automáticas com backoff exponencial para falhas transitórias. - Fila de mensagens mortas para mensagens venenosas; alertas e ferramentas de repetição. 7) Pipeline de Segmentação Promocional - Construtor de público geográfico: converte áreas geográficas (células geohash/H3) + critérios de elegibilidade em conjuntos de usuários-alvo. - Usa sinais de localização quase em tempo real (última localização conhecida) e/ou região de casa/trabalho. - Produz lotes de jobs de notificação em filas de menor prioridade com limitação. 8) Observabilidade e Operações - Métricas: latência de ponta a ponta p50/p95/p99, atraso da fila, taxas de erro do provedor, taxas de invalidação de token. - Rastreamento: correlaciona event_id → job_id → provider request_id. - Console de administração: gerenciamento de campanhas, repetição, listas de supressão. Principais escolhas tecnológicas e justificativa 1) Filas de mensagens / streaming de eventos - Apache Kafka (ou equivalentes gerenciados como AWS MSK / Confluent Cloud) como o barramento de eventos central. Justificativa: alta taxa de transferência durante horários de pico, particionamento para escala horizontal, log durável para repetição, grupos de consumidores para escalonamento independente, bom ajuste para processamento de pelo menos uma vez. - Tópicos separados para: - eventos-de-viagem (transacionais) - eventos-eta - eventos-promo - jobs-de-notificacao-alta (prioridade) - jobs-de-notificacao-baixa (promo) - resultados-de-entrega 2) Armazenamentos de dados - Tokens de dispositivo e preferências: DynamoDB (ou Cassandra) com chave user_id. Justificativa: leituras de baixa latência previsíveis em escala massiva, alta disponibilidade, fácil escalonamento horizontal. - Rastreamento de entrega / análise: - Caminho quente: DynamoDB/Cassandra para estado recente (último status por notification_id). - Análise de longo prazo: data lake (S3/GCS) + data warehouse (Snowflake/BigQuery) alimentado por Kafka Connect. - Metadados de campanha/público: Postgres (ou Aurora) para gerenciamento relacional (campanhas, agendamentos, criativos). - Cache: Redis (clusterizado) para consultas de token de dispositivo, cache de preferências do usuário e fragmentos de modelo. 3) Serviços de notificação push - APNs para iOS e FCM para Android. Justificativa: infraestrutura de push oficial, confiável e escalável; suporta prioridade e chaves de colapso. - Provedor SMS opcional para fallback para atender à confiabilidade de notificações transacionais críticas. 4) Segmentação geográfica - Indexação H3 ou Geohash para regiões geográficas. Justificativa: mapeamento eficiente de lat/lon para células discretas; suporta consulta de “usuários nessas células”. - Processamento de fluxo: Kafka Streams / Flink para manter a associação “usuários-na-célula” com base nas atualizações de localização. Baixa latência (<2s) e alta confiabilidade (pelo menos uma vez) 1) Estratégia de baixa latência - Priorizar notificações transacionais: - Usar tópicos/filas de alta prioridade dedicados e pools de workers. - Aplicar SLAs rigorosos por mensagem: janelas de lote curtas (ou nenhuma) para eventos urgentes. - Enriquecimento com cache primeiro: - O orquestrador lê tokens de dispositivo/preferências do Redis; volta para DynamoDB em caso de falha no cache. - Manter o payload mínimo; incluir deep links para buscar detalhes no aplicativo. - Minimizar dependências síncronas: - Produtores publicam eventos de forma assíncrona. - O orquestrador evita chamar vários microsserviços em linha; usa dados pré-computados (por exemplo, informações do motorista já no evento ou obtidas do cache). - Reutilização de conexão e melhores práticas do provedor: - Manter conexões HTTP/2 persistentes com APNs; reutilizar conexões FCM. - Usar sinalizadores de prioridade do provedor apropriadamente. - Controlar o ruído de “chegando em breve”: - O serviço de ETA emite apenas ao cruzar o limite com cooldown (por exemplo, não reenviar em N minutos) para reduzir a carga e manter a latência para mensagens críticas. 2) Entrega pelo menos uma vez e correção - Pelo menos uma vez do Kafka + commits do consumidor após o processamento. - Idempotência: - Cada job de notificação carrega uma chave de idempotência determinística (por exemplo, user_id + ride_id + event_type + version). - O orquestrador grava um registro de “job criado” (ou chave de deduplicação) com gravação condicional para evitar a criação de jobs duplicados em repetições. - Workers de entrega registram tentativas com chave notification_id para evitar o envio duplo quando possível. - Deduplicação no nível do provedor: - Usar chaves de colapso APNs/FCM para certos tipos (por exemplo, motorista chegando em breve) para garantir que o mais recente substitua o anterior. - Política de retentativa: - Falhas transitórias: retentar com backoff exponencial e jitter. - Falhas permanentes (token inválido): marcar token como inválido, parar de retentar. - DLQ para falhas repetidas; fluxos de trabalho do operador para repetição. 3) Confiabilidade e disponibilidade - Implantação Multi-AZ para Kafka, Redis, DynamoDB (gerenciado) e serviços sem estado. - Backpressure: - Se os provedores de push degradarem, as filas absorvem picos; os workers escalam, mas com limite para evitar limites de taxa do provedor. - O exatamente uma vez não é necessário; pelo menos uma vez com idempotência é suficiente para notificações voltadas para o usuário. Escalando para lidar com cargas de pico 1) Estimativa de taxa de transferência (ordem de magnitude) - 500 mil viagens/dia; cada viagem pode gerar 2–4 notificações transacionais (atribuída, chegando em breve, concluída/recibo) para o passageiro; mais notificações para o motorista. - Picos durante o horário de pico podem ser 10–20x a média. Projetar para vários milhares de notificações/segundo em rajadas sustentadas. 2) Abordagem de escalonamento horizontal - Particionamento do Kafka: - Particionar por user_id (ou ride_id) para manter a ordem por usuário/viagem para notificações relacionadas. - Escalar partições para corresponder ao paralelismo esperado do consumidor de pico. - Serviços sem estado: - Orquestrador e workers de entrega são sem estado e escalados automaticamente (HPA do Kubernetes com base em CPU + atraso da fila). - Pools separados e isolamento: - Tópicos/filas e implantações de workers separados para transacional vs promocional. - Quotas rígidas para que promoções nunca sufoquem a entrega transacional. 3) Escalabilidade de mensagens promocionais - Pré-calcular público: - A campanha se expande para células H3; busca usuários elegíveis por meio do armazenamento “usuários-na-célula”. - Fanout em lotes com limitação; enfileira jobs na fila de baixa prioridade. - Limitação de taxa: - Limites globais e por região; divisão de tempo entre células. - Respeitar limites de frequência por usuário e opt-outs. 4) Escalabilidade de dados e cache - Cluster Redis dimensionado para alta leitura de QPS; usar hashing consistente e replicação. - DynamoDB/Cassandra com capacidade de leitura suficiente; o cache o protege durante picos. - Tratamento de invalidação de token para reduzir envios falhos repetidos. Principais compensações 1) Pelo menos uma vez vs exatamente uma vez - Compensação: pelo menos uma vez pode causar duplicatas; exatamente uma vez adicionaria complexidade e latência. - Decisão: aceitar pelo menos uma vez com chaves de idempotência fortes e chaves de colapso para minimizar duplicatas visíveis para o usuário. 2) Consistência vs disponibilidade - Tokens/preferências de dispositivo podem estar ligeiramente desatualizados (consistência eventual) se um usuário alterar as configurações. - Decisão: favorecer disponibilidade e baixa latência; usar caches com TTL curto e versionamento para convergir rapidamente. 3) Custo vs desempenho - Manter um índice de público geográfico em tempo real e um processador de fluxo custa mais do que a segmentação em lote. - Decisão: usar segmentação geográfica quase em tempo real apenas quando necessário; caso contrário, permitir campanhas com expansão em lote mais lenta. Isolar cargas de trabalho de promoções em capacidade mais barata. 4) Abordagem de enriquecimento de payload - Mensagens totalmente enriquecidas exigem mais leituras síncronas e podem aumentar a latência. - Decisão: manter o payload push pequeno e depender de deep links; enriquecer apenas quando os dados já estiverem no evento ou em cache. 5) Dependências do provedor e fallback - Adicionar fallback SMS aumenta o custo e o escopo de conformidade. - Decisão: habilitar fallback SMS apenas para notificações transacionais críticas (por exemplo, motorista atribuído/chegando) e apenas quando o push falhar repetidamente ou o usuário não tiver um token válido. Resumo Este projeto usa um backbone de streaming de eventos durável (Kafka), um orquestrador de notificações baseado em regras e workers de entrega de canal escaláveis para obter entrega de notificações transacionais abaixo de 2 segundos com confiabilidade de pelo menos uma vez. Ele escala horizontalmente via particionamento e escalonamento automático, isola o tráfego promocional para proteger mensagens sensíveis ao tempo e gerencia duplicatas por meio de idempotência e chaves de colapso do provedor, ao mesmo tempo em que equilibra custo e complexidade operacional.

Sistema de Notificação de Compartilhamento de Viagens em Tempo Real: Design de Arquitetura de Alto Nível Visão Geral O sistema de notificação deve entregar de forma confiável mensagens sensíveis ao tempo para 1 milhão de usuários ativos diariamente em 500.000 viagens diárias, com latência inferior a 2 segundos e garantias de entrega pelo menos uma vez. O design segue uma arquitetura orientada a eventos e microsserviços com separação clara entre produção de eventos, roteamento, entrega e rastreamento. --- 1. Componentes Arquitetônicos de Alto Nível e Interações O sistema é composto por cinco camadas principais: Produtores de Eventos: Os serviços principais de correspondência de viagens e gerenciamento de viagens emitem eventos de domínio (motorista atribuído, motorista chegando, viagem concluída, promoção acionada) para um broker de mensagens central. Esses serviços são totalmente desacoplados do sistema de notificação. Broker de Mensagens (Barramento de Eventos): Uma plataforma de streaming distribuída ingere todos os eventos e os distribui para consumidores downstream. Este é o backbone do pipeline assíncrono. Serviço Orquestrador de Notificações: Um microsserviço sem estado que consome eventos do broker, os enriquece com preferências do usuário e tokens de dispositivo (obtidos de um Armazenamento de Perfil do Usuário), determina o canal de notificação correto (push, SMS, in-app) e publica trabalhos de notificação formatados em filas específicas do canal. Trabalhadores de Entrega de Canal: Pools de trabalhadores dedicados para cada canal (APNs para iOS, FCM para Android, Twilio para SMS, servidor WebSocket para in-app). Cada trabalhador consome de sua fila, chama o gateway de terceiros apropriado e registra o status da entrega. Armazenamento de Rastreamento e Auditoria de Entrega: Um log persistente de cada tentativa de notificação, seu status (enviado, entregue, falhou) e timestamps. Isso alimenta dashboards e lógica de retentativa. Resumo do fluxo: Serviço de viagem emite evento → Broker de mensagens → Orquestrador enriquece e roteia → Fila de canal → Trabalhador de entrega → Gateway de push/SMS → Dispositivo. O status da entrega é gravado de volta no armazenamento de auditoria de forma assíncrona. --- 2. Principais Escolhas Tecnológicas e Justificativas Broker de Mensagens: Apache Kafka. O Kafka fornece streaming de eventos de alto rendimento, durável e ordenado com retenção configurável. Seu modelo de grupo de consumidores permite que várias instâncias do orquestrador processem eventos em paralelo. O fator de replicação do Kafka (definido como 3) garante que nenhum evento seja perdido se um nó do broker falhar. Para picos de hora de pico, o Kafka absorve rajadas sem back-pressure nos serviços upstream. Orquestrador e Trabalhadores: Microsserviços Go ou Java implantados no Kubernetes. Go oferece baixa sobrecarga de memória e alta concorrência via goroutines, ideal para despacho de notificações com I/O limitado. O Kubernetes permite escalonamento automático horizontal de pods com base em métricas de lag do consumidor Kafka. Armazenamento de Perfil do Usuário e Token de Dispositivo: Redis (primário, para dados quentes) com backup no PostgreSQL (fonte da verdade). Tokens de dispositivo e preferências do usuário são cacheados no Redis com um TTL. O padrão cache-aside garante que o orquestrador recupere tokens em menos de 1 ms em caso de acerto no cache, evitando gargalos no banco de dados em escala. Gateways de Notificação Push: Firebase Cloud Messaging (FCM) para Android e Apple Push Notification service (APNs) para iOS. Ambos suportam APIs de envio em lote. Para fallback de SMS, o Twilio oferece entrega global confiável com recibos de entrega. Canal In-App / Tempo Real: Um gateway WebSocket (usando Socket.io ou um servidor personalizado com suporte a Redis Pub/Sub) mantém conexões persistentes com sessões de aplicativos ativas. Para notificações de motorista chegando e motorista atribuído, o canal in-app é tentado primeiro porque é o caminho de menor latência. Armazenamento de Auditoria de Entrega: Apache Cassandra ou Amazon DynamoDB. Ambos são otimizados para alto rendimento de gravação e padrões de acesso a séries temporais. Cada tentativa de notificação é gravada como um registro imutável com chave (user_id, notification_id, timestamp). Direcionamento Geográfico para Promoções: Um índice geoespacial usando PostGIS ou Redis com comandos GEO armazena as últimas localizações conhecidas dos usuários. Um serviço de campanha promocional consulta esse índice para construir listas de usuários-alvo, em seguida, publica eventos de notificação individuais no Kafka, mantendo o pipeline de entrega uniforme. --- 3. Estratégia de Baixa Latência e Alta Confiabilidade Baixa Latência (inferior a 2 segundos ponta a ponta): O caminho crítico para notificações transacionais (motorista atribuído, motorista chegando) é: emissão de evento → ingestão Kafka (< 10 ms) → processamento do orquestrador, incluindo consulta de token Redis (< 50 ms) → chamada da API FCM/APNs (geralmente 100–400 ms) → recebimento do dispositivo. A latência total esperada p99 está bem abaixo de 2 segundos sob carga normal. Para minimizar o tempo de processamento do orquestrador, o enriquecimento de token é feito por meio de uma única chamada de pipeline Redis em vez de consultas sequenciais. O orquestrador é sem estado e escalado horizontalmente, portanto, nenhuma instância única é um gargalo. A entrega via WebSocket para notificações in-app contorna totalmente os gateways de push, alcançando entrega inferior a 100 ms para usuários com sessões ativas. Alta Confiabilidade (entrega pelo menos uma vez): Offsets do consumidor Kafka são confirmados apenas após o orquestrador ter publicado com sucesso o trabalho de notificação na fila do canal. Se o orquestrador falhar no meio do processamento, o evento é re-consumido e reprocessado. Trabalhadores de entrega de canal usam uma chave de idempotência (derivada do notification_id) ao chamar FCM/APNs, evitando notificações duplicadas mesmo que um trabalhador retente após uma falha transitória. Uma fila de mensagens mortas (DLQ) captura notificações que falham após um número configurável de retentativas (por exemplo, 3 tentativas com backoff exponencial). Um sistema de alerta monitora a profundidade da DLQ e aciona escalonamento de plantão. Para fallback de SMS: se a entrega push não for confirmada em 30 segundos (verificado por meio de recibos de entrega FCM), o sistema reverte automaticamente para SMS para notificações críticas (motorista atribuído, viagem concluída). --- 4. Estratégia de Escalabilidade para Cargas de Pico Picos de hora de pico são previsíveis (manhã e noite). O sistema usa duas abordagens de escalonamento complementares: Escalonamento Proativo (Agendado): O Horizontal Pod Autoscaler (HPA) do Kubernetes é pré-aquecido antes das janelas de pico conhecidas usando uma política de escalonamento baseada em cron. As contagens de réplicas do orquestrador e dos trabalhadores são aumentadas 10 minutos antes da hora de pico. Escalonamento Reativo: O lag do consumidor Kafka é exposto como uma métrica personalizada para o Kubernetes Metrics Server. Se o lag no tópico de notificação exceder um limite (por exemplo, 10.000 mensagens não processadas), o HPA adiciona pods do orquestrador automaticamente. Pools de trabalhadores escalam de forma semelhante com base nas profundidades de suas filas. Particionamento Kafka: O tópico de notificação é particionado por user_id (ou ride_id) para garantir o processamento ordenado por usuário, permitindo alta paralelização. Com 100 partições, até 100 instâncias do orquestrador podem processar simultaneamente. Notificações de promoção, que são em massa e não críticas em termos de tempo, são processadas em um tópico Kafka separado de menor prioridade com um grupo de consumidores dedicado. Isso evita que rajadas promocionais compitam com notificações transacionais por recursos de processamento. Escalonamento de banco de dados: Redis é implantado como um cluster com réplicas de leitura. PostgreSQL usa pool de conexões (PgBouncer) e réplicas de leitura para consultas de perfil. Cassandra escala horizontalmente adicionando nós. Taxa de transferência estimada: 500.000 viagens/dia com uma média de 3 notificações por viagem totaliza 1,5 milhão de notificações transacionais por dia, ou aproximadamente 17 por segundo em média. Durante um pico de hora de pico de 2 horas lidando com 30% das viagens diárias, a taxa de transferência de pico atinge aproximadamente 70 notificações por segundo. Isso está bem dentro da capacidade de um cluster Kafka e de trabalhadores modesto, deixando ampla margem. --- 5. Principais Compromissos Entrega Pelo Menos Uma Vez vs. Entrega Exatamente Uma Vez: A entrega exatamente uma vez em sistemas distribuídos e gateways de terceiros (FCM, APNs) é praticamente impossível de garantir ponta a ponta. O design aceita semânticas pelo menos uma vez e mitiga a entrega duplicada usando chaves de idempotência. O compromisso é com notificações duplicadas ocasionais (por exemplo, duas mensagens "motorista atribuído") em vez da complexidade e custo de latência de transações distribuídas. Para um aplicativo de compartilhamento de viagens, um duplicado raro é muito menos prejudicial do que uma notificação perdida. Custo vs. Desempenho: Manter uma conexão WebSocket persistente para cada usuário ativo é caro em termos de recursos de servidor. O design usa WebSockets apenas para usuários com sessões de aplicativo ativas (geralmente durante uma viagem ativa), recorrendo a notificações push caso contrário. Isso reduz o custo da infraestrutura enquanto preserva a baixa latência para os momentos mais críticos. Consistência vs. Disponibilidade: O cache de token Redis pode servir um token de dispositivo desatualizado se um usuário reinstalar o aplicativo e o cache ainda não tiver sido invalidado. O design aceita essa janela de consistência eventual (geralmente segundos a minutos) em troca dos benefícios de disponibilidade e latência do cache. Uma push falha devido a um token desatualizado aciona uma atualização de cache e retentativa, portanto, o impacto é uma notificação ligeiramente atrasada em vez de uma perdida. Simplicidade vs. Flexibilidade no Roteamento de Canal: Um mecanismo de roteamento mais sofisticado poderia aplicar modelos de aprendizado de máquina para escolher o canal ideal por usuário. O design atual usa um roteador baseado em regras simples (in-app primeiro, depois push, depois fallback SMS) para previsibilidade, menor complexidade operacional e depuração mais fácil. Isso pode ser evoluído incrementalmente. Isolamento de Promoção: Separar o tráfego promocional em seu próprio tópico Kafka e pool de trabalhadores adiciona complexidade operacional (mais tópicos para monitorar, mais grupos de consumidores para gerenciar), mas é um compromisso necessário para proteger os SLAs de notificação transacional de serem degradados por envios promocionais em massa. --- Conclusão Esta arquitetura oferece um sistema de notificação robusto e escalável, combinando o streaming de eventos durável do Kafka, o enriquecimento de baixa latência com suporte a Redis, trabalhadores de entrega multicanal e escalonamento automático baseado em Kubernetes. O design prioriza a entrega inferior a 2 segundos para notificações transacionais e confiabilidade pelo menos uma vez por meio de retentativas idempotentes e filas de mensagens mortas, ao mesmo tempo em que isola o tráfego promocional para proteger a experiência principal do usuário. Os compromissos feitos favorecem a simplicidade operacional e a disponibilidade em detrimento da perfeição teórica, o que é apropriado para um produto de consumo de alta velocidade.