Como o Patreon escalou seu sistema de notificações com fanout

• O sistema de 13 anos que vinha processando dezenas de bilhões de notificações por ano começou a sofrer timeouts quando um único grande creator gerava milhões de eventos, então o Patreon o redesenhou com uma camada de fanout que pré-cria notificações por destinatário
• Aplicou um fanout em duas etapas, dividindo a lista de destinatários em pequenos lotes e processando feed no app, push e e-mail de forma independente, garantindo escalabilidade horizontal e isolamento de falhas entre canais
• Para grandes creators, push e feed no app ficaram 80% mais rápidos, e e-mail 55% mais rápido; quando o público quadruplica, o aumento da latência ponta a ponta caiu de 186% para 33% e 60%, respectivamente
• Com a Notification Factory e uma API única, send_fanout_notifications, o Patreon padronizou filtragem, verificação de elegibilidade e geração de payloads, além de rastrear tempos por etapa e resultados por destinatário para simplificar operações e debugging
• 10 equipes e mais de 30 engenheiros migraram mais de 200 notificações, e a geração de rascunhos com IA junto com um prazo claro definido pela liderança ajudou a reduzir trabalho repetitivo e a operação paralela prolongada

---

Os limites de escala expostos pelos grandes creators

• O Patreon envia dezenas de bilhões de notificações por ano para fãs quando creators publicam posts ou iniciam livestreams
• Com o lançamento das assinaturas gratuitas e o crescimento da plataforma, o número de fãs por creator disparou, e no início de 2025 gargalos graves de desempenho começaram a aparecer, especialmente entre os grandes creators
• As notificações de post antigas usavam uma única tarefa assíncrona para buscar todos os destinatários, filtrar por preferências de cada usuário, gerar o payload de cada destinatário e então encaminhar tudo para os sistemas de entrega de feed no app, push e e-mail
• No caso dos grandes creators, uma única tarefa passou a ser responsável por gerar milhões de notificações, causando timeouts constantes e dificultando a entrega confiável para audiências enormes
• O fluxo antigo tinha duas limitações estruturais
  • O custo de geração por destinatário ficava concentrado em uma única tarefa assíncrona, o que impossibilitava escalabilidade horizontal e criava um teto claro de throughput
  • Feed no app, push e e-mail eram fortemente acoplados, então a falha de um canal podia bloquear os demais
• Várias equipes de produto criaram estratégias próprias de escala para notificações de alto volume, o que resolveu problemas de curto prazo, mas aumentou a complexidade da plataforma e dificultou desenvolvimento, operação e debugging
• A decisão foi manter os sistemas de entrega existentes, mas colocar na frente deles uma camada comum de fanout para oferecer escalabilidade horizontal, isolamento por canal e observabilidade

Seis requisitos de projeto para a plataforma de fanout

• A nova camada foi desenhada para dividir listas grandes de destinatários em pequenos lotes, gerar notificações por destinatário e então entregá-las aos sistemas existentes de feed no app, push e e-mail
• A plataforma adotou os seis requisitos abaixo
  • Facilidade para desenvolvedores: notificações de alto volume não deveriam exigir que cada equipe resolvesse escalabilidade e confiabilidade do zero, e a plataforma precisava reduzir erros de uso enquanto suportava vários casos
  • Escalabilidade horizontal: a lista de destinatários precisava ser dividida automaticamente em pequenos lotes para processamento assíncrono
  • Isolamento por canal: feed no app, push e e-mail precisavam rodar de forma independente para que a falha de um canal não se propagasse aos outros
  • Processamento por prioridade: notificações sensíveis a tempo deveriam usar filas dedicadas e pools de workers separados das notificações comuns
  • Observabilidade: era preciso investigar resultados de filtragem e entrega e medir a latência ao longo de todo o ciclo de vida da notificação
  • Extensibilidade: recursos futuros, como geração da lista de destinatários, deveriam poder ser adicionados sem outro grande refactor

Separando a lógica de negócio com Notification Factory

• Para separar a orquestração da plataforma da lógica de negócio específica de cada notificação, o Patreon introduziu a abstração Notification Factory
• Cada factory define o blueprint do processamento de uma notificação com os seguintes elementos
  • prioridade de processamento
  • configurações de notificação aplicáveis
  • forma de filtrar destinatários
  • verificação de elegibilidade específica da notificação
  • forma de gerar payloads por canal
• Esse padrão é baseado no motor interno de tarefas distribuídas do Patreon e compartilha vários conceitos com ele
• O modelo Notification define os argumentos da tarefa que contêm dados únicos de uma notificação específica e compartilhados por todos os destinatários
• A subclasse correspondente de BaseNotificationFactory atua como o handler da tarefa e contém as configurações e métodos para filtrar destinatários e gerar notificações
• Para que a tarefa de fanout, que recebe apenas payloads serializados de notificação, consiga localizar a lógica de negócio que deve executar, o Patreon usa um registro que mapeia cada modelo Notification para sua classe factory correspondente
• Era necessário suportar diferentes tipos de notificação e, ao mesmo tempo, evitar erros comuns de implementação e consultas de dados ineficientes
  • Como o Patreon tem vários tipos de registros de usuário e diferentes formas de filtragem, a interface de destinatário foi generalizada
  • Também foram fornecidos hooks claros para implementar preferências do usuário e verificações de elegibilidade específicas de cada notificação

Uma API única e fanout em duas etapas

• Antes, cada canal usava APIs de envio separadas, o que fazia os fluxos de feed no app, push e e-mail divergirem e forçava as equipes de produto a pensar cedo demais no comportamento específico de cada canal
• Após o redesenho, o ponto de entrada foi unificado em uma API única: send_fanout_notifications
  • Quem chama a API envia o payload da notificação, a lista de destinatários e um timestamp usado para medir a latência de entrega
  • A API localiza a factory correspondente à notificação, define tamanho de lote e prioridade e distribui tarefas por canal de forma independente
  • Falhas ou atrasos em um canal não bloqueiam os outros
• A primeira etapa cuida da escala da geração de notificações
  • A lista completa de destinatários é dividida em pequenos lotes
  • Cada lote é processado pela tarefa FanoutNotifications
  • A tarefa filtra destinatários, executa verificações de elegibilidade específicas da notificação e usa a Notification Factory para gerar payloads por canal
• A segunda etapa cuida da escala da transferência para entrega
  • As notificações geradas passam por novo fanout para tarefas de entrega dedicadas a feed no app, push e e-mail
• O handler central, FanoutNotifications, fica entre a API e os sistemas legados de entrega por canal, transformando uma tarefa gigantesca em várias tarefas pequenas que podem ser processadas de forma independente

Observabilidade e debugging por destinatário

• Notificações podem falhar ou ser ignoradas por vários motivos, como o usuário ter desativado as preferências, não passar na verificação de elegibilidade ou não poder receber por e-mail
• Na plataforma antiga, para verificar o resultado do processamento de uma notificação específica era preciso juntar logs e dados de vários sistemas, e como não havia rastreamento abrangente por destinatário, investigações podiam levar horas
• A nova plataforma foi projetada para responder às seguintes perguntas
  • quanto tempo levou para enviar a notificação
  • qual era o tamanho da lista inicial de destinatários
  • quantas pessoas foram filtradas e por quais motivos
  • quantas entregas foram bem-sucedidas por canal
  • por que um usuário específico recebeu ou não recebeu uma notificação específica
• Foi introduzido um modelo de dados de timing e logging propagado por toda a plataforma
  • timestamps são registrados em cada etapa do fluxo da notificação
  • métricas e eventos são gerados tanto para resultados agregados quanto para resultados por destinatário
  • desenvolvedores podem anexar propriedades de logging para incluir entidades relacionadas em traces de execução e eventos
• Com melhorias em observabilidade, alertas, dashboards e ferramentas de debugging, engenheiros de produto e equipes de suporte passaram a conseguir investigar mais problemas sem depender da equipe de plataforma

Migração de mais de 200 notificações

• Como o padrão Notification Factory mudou a própria forma de desenvolver e manter notificações, não era possível migrar apenas com uma simples ferramenta de transformação de código (codemod)
• Era necessário preservar exatamente a lógica de negócio, dependências de dados, regras de elegibilidade e comportamento por canal de cada notificação
• Com base na documentação de migração e em PRs exemplares feitos manualmente, o Patreon criou uma skill de IA
  • Desenvolvedores podiam executar /migrate-notif-fanout <notif_name> para gerar um primeiro resultado de migração
  • Isso foi eficaz em tarefas repetitivas como criar o modelo da notificação, conectar a factory, ajustar pontos de chamada e aplicar os padrões da plataforma
• A IA não substituiu o julgamento de engenharia, porque podia deixar passar lógica de negócio sutil, alucinar e gerar código duplicado que exigia limpeza
• Mais de 200 notificações foram migradas, e com colaboração em grande escala incluindo uso de IA, os 80% restantes foram concluídos em 6 semanas

Ganhos de desempenho e impacto no desenvolvimento de produto

• Ao mover a geração de notificações por destinatário para tarefas com escalabilidade horizontal, o Patreon passou a conseguir gerar de forma estável milhões de notificações por creator sem timeouts
• O desempenho de notificações de alto volume para grandes creators melhorou significativamente
  • push e feed no app ficaram 80% mais rápidos
  • notificações por e-mail ficaram 55% mais rápidas
  • quando a audiência quadruplica, a latência ponta a ponta de push e feed no app aumenta 33%, e a de e-mail, 60%
  • nas mesmas condições, a plataforma antiga tinha aumento de latência de 186%
• As equipes de produto deixaram de precisar desenhar soluções de escala separadas para cada notificação de alto volume, e a velocidade de desenvolvimento também melhorou
• A nova plataforma sustentou lançamentos importantes de 2025, como Lives, Quips e iniciativas para atrair grandes creators
• Sem o redesenho com fanout, esses lançamentos teriam esbarrado nos gargalos existentes e exigido mais tempo de engenharia para criar soluções pontuais de escala
• Com métricas de timing por etapa, a equipe passou a identificar onde o tempo está sendo gasto e ajustar a infraestrutura de acordo com o equilíbrio desejado entre velocidade e custo

Nove meses de operação paralela e coordenação organizacional

• A parte mais difícil foi alterar um sistema legado em produção enquanto se coordenava a migração entre várias equipes
• Os dois sistemas de notificação rodaram em paralelo por 9 meses
  • Toda mudança de plataforma precisava ser compatível tanto com o caminho antigo quanto com o novo caminho com fanout
  • O escopo para bugs e incidentes aumentou, e quanto mais a migração se prolongava, maior ficava o risco operacional
  • Alguns incidentes menores causados por problemas de compatibilidade reforçaram a necessidade de concluir a migração com rapidez e segurança
• No início, o Patreon adotou uma abordagem bottom-up, em que cada equipe de produto definia a prioridade da própria migração de notificações
  • Em 6 meses, apenas cerca de 20% tinham sido migradas
  • O ritmo desacelerava porque a migração perdia espaço para roadmaps de produto e outras prioridades de equipe
• Depois que a liderança de engenharia concordou com a conclusão no 1º trimestre de 2026 e definiu um prazo claro com prioridade em toda a empresa, o restante da migração foi concluído em 6 semanas
• O trabalho total envolveu 10 equipes e mais de 30 engenheiros
  • um tracker no Notion e automações foram usados para acompanhar o progresso
  • houve comunicação frequente com stakeholders e distribuição do trabalho entre várias equipes
  • a equipe de plataforma executou cerca de metade das migrações e depois repassou deploy e limpeza para as equipes donas das notificações
  • a carga foi distribuída para evitar concentração de trabalho nas equipes com mais notificações
• Também foi realizada uma semana de migração de notificações com office hours, leaderboard, brindes e happy hour para acelerar o progresso e celebrar a conclusão
• Houve ainda uma folga de 2 semanas antes do prazo final da transferência
  • esse tempo foi usado para ajudar equipes que precisavam de suporte adicional e procurar trabalhos pendentes no codebase
  • na checagem final foram encontradas 4 novas migrações necessárias e vários itens incompletos, todos resolvidos com impacto pequeno no cronograma

Lições de uma grande migração de plataforma

• Sem prioridade explícita, migrações que atravessam várias equipes competem com o roadmap de cada time e são facilmente adiadas
  • Isso fica especialmente evidente na longa cauda das notificações de baixo volume, em que o ganho de escala é menos visível
  • Alinhamento da liderança, prioridade compartilhada e prazo claro foram essenciais para concluir a migração em um tempo razoável

• O trabalho de plataforma não termina na API

  • Antes, investigar dúvidas sobre notificações de outras equipes e problemas de entrega consumia boa parte do plantão on-call dos engenheiros de plataforma
  • Melhorias em observabilidade, alertas, dashboards e ferramentas de debugging precisavam vir junto para que equipes de produto e suporte pudessem investigar de forma independente e para reduzir a carga de on-call da plataforma
  • Era preciso considerar não só o gargalo atual, mas também o próximo gargalo
  • Um único projeto não conseguiria resolver todos os problemas de escala de notificações
  • O sistema foi projetado para acomodar recursos futuros e reduzir a chance de outra grande refatoração quando o volume de notificações continuar aumentando

O próximo gargalo e os planos futuros

• A geração de notificações foi escalada, mas o próximo gargalo é a geração da lista de destinatários
• À medida que o público-alvo continua crescendo, consultar com eficiência milhões de destinatários se torna cada vez mais importante
• O plano é incorporar a geração da lista de destinatários à Notification Factory para que a plataforma assuma mais do fluxo de notificações de ponta a ponta
• As configurações de notificação também serão melhoradas tanto para desenvolvedores quanto para fãs
  • desenvolvedores terão mais facilidade para criar e gerenciar novas configurações
  • fãs terão uma experiência melhor para entender e controlar suas preferências de notificação