O que são notificações de alto volume?
As notificações de alto volume se situam entre o transacional e o marketing em termos de volume, mas compartilham com o transacional a sensibilidade ao tempo. Os exemplos típicos: notificações de produto SaaS (alguém te mencionou, seu build falhou, sua fatura vence em 3 dias), alertas financeiros (limiar de saldo, detecção de fraude, advertência de segurança sobre login desde IP desconhecida), páginas operativas (seu incidente está escalando, seu deploy terminou, seu monitoring disparou alerta), notificações de marketplace (você recebeu uma mensagem, alguém comprou seu produto, alguém deixou review). O volume é alto —às vezes milhões diários distribuídos em uma base de clientes— mas cada mensagem individual precisa aterrissar em segundos porque há um destinatário esperando. O problema arquitetônico é sustentar taxa pico de envio sem sacrificar latência por mensagem, e isso exige disciplina específica que muitos provedores não têm porque projetaram para ou transacional puro ou marketing puro.
Por que o burst bimodal quebra a maioria dos provedores?
Um burst de notificações é bimodal por natureza: 95% do tempo você está enviando a 1-5K/hora, e então um evento desencadeante —um deploy, um movimento de mercado, um incidente de segurança em um dos seus clientes, uma queda de serviço de um provedor que afeta vários— provoca que você envie 500K mensagens em 15 minutos. A maioria dos provedores maneja o steady state corretamente e se engasga no burst. O engasgo adota formas distintas: SES limita rate e enfileira internamente com atraso multi-minuto que é invisível ao cliente até que apareça; SendGrid Pro throttlea para proteger sua infraestrutura compartilhada; os serviços gerenciados com caps de capacidade horários rejeitam submissions até que a janela do rate se resete. Projetamos especificamente para o caso de burst: 2× headroom permanente em cada PoP, capacidade de burst-absorption pré-provisionada, filas de despacho separadas para tráfego time-sensitive vs background. A ideia: você não quer descobrir que seu provedor se engasga no dia que sua plataforma tem um incidente.
O que torna esta categoria distinta do marketing e do transacional.
As notificações diferem do marketing porque o destinatário está realmente esperando (engajamento não é opcional, é o propósito completo da mensagem). Diferem do transacional porque o volume por evento pode ser 100-1000× o steady state, o que faz com que o dimensionamento estável não baste. Compartilham com o transacional o requisito de baixa latência, e compartilham com o marketing o requisito de alto throughput. A maioria dos senders nesta categoria opera um setup híbrido: um pool transacional pequeno para OTPs e password resets, um pool de notificações que escala para bursts, e às vezes um pool separado de marketing. Suportamos os três na mesma conta com pools de IP separados, estatísticas separadas, webhooks separados routáveis a endpoints distintos conforme o fluxo. A separação importa porque um complaint spike em marketing não deve degradar a entrega dos seus alertas de segurança.
Por que webhooks confiáveis importam tanto em notifications?
Em notifications, os webhooks não são nice-to-have: são o contrato entre sua plataforma e a nossa. Cada vez que enviamos um evento (queued, delivered, bounced, deferred, complained, replied) entregamos o webhook assinado com HMAC-SHA256 sobre o body completo, com timestamp Unix em epoch segundos dentro da assinatura para proteção anti-replay com janela 5 minutos. O header de assinatura é X-OSD-Signature com formato v1=hex_hash. A idempotência é responsabilidade do receiver mas fazemos o que podemos para facilitar: cada evento leva um message_id único, então seu endpoint pode usá-lo como idempotency key e descartar duplicatas durante uma janela razoável (recomendamos 7 dias, que coincide com nosso retention). O esquema CloudEvents v1.0 torna nosso payload interoperável com AWS EventBridge, Google Eventarc, Knative e Argo Events sem parsing custom. Se seu endpoint cair, reenviamos por 30 minutos com backoff exponencial (5s, 25s, 125s, 625s, 3125s); passada essa janela os eventos vão ao buffer de replay de 7 dias onde ficam disponíveis para drenagem cronológica quando seu endpoint voltar. O replay manual desde painel está disponível para Performance e Enterprise.
Cross-PoP failover e por que Performance vale a pena para notifications.
Os clientes Performance e Enterprise têm routing multi-PoP: se um PoP perde transit (porque um dos IXs cai, porque há um BGP problem que um upstream demora a resolver, porque um datacenter tem incidente com seu transit principal), o tráfego se desvia ao PoP alterno em menos de 30 segundos. Os planos Starter e Standard são single-PoP e veriam a interrupção durante toda a duração do incidente upstream. Recomendamos Performance para qualquer workload de notifications que não tolere uma hora de regional outage, que é basicamente todas as notifications operacionais críticas. A diferença de preço entre Standard e Performance se amortiza na primeira vez que seu PoP principal tem incidente e o tráfego muda transparentemente, o que acontece estatisticamente 1-3 vezes por ano dependendo da região.
Como se gerencia o fanout a múltiplos provedores em um evento crítico?
Quando um único evento dispara fanout (status page incident → 50K customer alerts simultâneos, deploy completado → 10K developer notifications, market move → 200K subscriber alerts), a dinâmica com provedores de caixa muda. Enviar 50K mensagens em 5 minutos a uma mistura de Gmail, Outlook 365, Yahoo e Exchange corporativos está bem para Gmail (aceita essa taxa com pool adequado), mas Outlook rate-limita por domínio remetente e Yahoo deferre se seu backend vê um spike. Nosso scheduler suaviza a taxa per-provedor automaticamente para que nenhum provedor receba o burst completo de uma vez: se você tem 50K mensagens para enviar e seu pool tem capacidade sustentada de 5K/min, o scheduler distribui o burst em 10-12 minutos repartido por provedor. O destinatário recebe a mensagem em segundos individuais, mas a fila interna evita gerar um padrão que ativaria defesas anti-abuse do lado do receiver. Isso se chama smart fanout na nossa documentação e está ativo por padrão em Standard, Performance e Enterprise.
Padrões de digest: o caso especial de notificações agrupadas.
Algumas notificações são por natureza digest: o resumo diário de atividade, a lista semanal de mentions, o relatório das últimas 24 horas. Estas não têm a urgência per-mensagem dos alertas operacionais, mas têm um padrão de envio massivo concentrado em uma janela curta (tipicamente entre 7:00 e 9:00 hora local do destinatário). O desafio operacional é enviar a uma base de 1-10M destinatários em distintos fusos horários e respeitar o "envia às 8:00 hora local de cada usuário" sem que o envio total se concentre em poucas horas UTC que saturariam os pools. Suportamos timezone-aware scheduling: você passa à API o timestamp desejado em UTC mais a timezone preferida do destinatário, e nossa fila calcula o momento real de envio e o distribui ao longo das 24 horas seguindo o padrão geográfico da sua base.
Como se integra com PagerDuty, Opsgenie e status pages?
O uso mais crítico de notifications é o de incidentes operacionais: quando sua plataforma tem um incidente, os assinantes da sua status page recebem e-mails imediatos, os oncall dos seus clientes recebem page emails (se você integrou com o sistema deles), e sua própria equipe recebe escalation emails. A latência importa mais aqui que em qualquer outro lugar: um minuto de atraso no incident notification pode significar que um cliente fica sabendo pelo Twitter antes que por e-mail, o que danifica a confiança. Integramos com PagerDuty, Opsgenie e os status page providers mais comuns (Statuspage da Atlassian, Better Stack, Instatus, Cachet) via webhooks bidirecionais: eles disparam o evento, nós entregamos as mensagens, as acks voltam ao seu sistema para que seu dashboard mostre quantos assinantes receberam e quantos fizeram click. Para Performance e Enterprise, nosso próprio on-call está assinado a alertas de degradação da sua conta —se sua latência ou entrega cair, paginamos a nosso engenheiro em 5 minutos antes que você escreva o ticket.
Notifications de segurança: login alerts, anomalias de fraude, mudanças de senha.
As notificações de segurança merecem tratamento à parte porque caem em uma zona cinza regulatória. Um e-mail de "foi iniciada sessão na sua conta desde uma nova localização" não é marketing nem transacional puro: é uma notificação de proteção ao usuário. No Brasil, a Resolução BCB 4.893/2021 sobre política de segurança cibernética exige medidas técnicas razoáveis para detecção e notificação de eventos de risco para fintechs reguladas. Na UE, sob PSD2 SCA (Directiva (UE) 2015/2366), estas notificações são requerimento explícito para entidades financeiras quando se detecta risco. Para SaaS B2B a pressão regulatória vem de NIS2 (Directiva (UE) 2022/2555) e das obrigações de reportes de incidentes do Regulamento DORA. A consequência operacional: este tráfego não aceita nem um atraso de 60 segundos porque o atacante pode ter já trocado a senha e escalado privilégios. Cap diário por destinatário muito alto (os usuários sob ataque recebem muitos eventos seguidos), latência P99 medida e reportada separadamente, pool de IP dedicado distinto do de marketing e do transacional geral.