Comment Patreon a fait évoluer son système de notifications avec le fan-out

• Le système vieux de 13 ans, qui traitait des milliards de notifications par an, s’est heurté à des timeouts lorsque de grands créateurs généraient chacun des millions de notifications ; Patreon l’a donc repensé avec une couche de fan-out qui pré-génère les notifications par destinataire
• En découpant les listes de destinataires en petits lots et en traitant indépendamment le fil in-app, les push et les e-mails via un fan-out en deux étapes, Patreon a obtenu une scalabilité horizontale et isolé les pannes par canal
• Pour les grands créateurs, les notifications push et in-app sont devenues 80 % plus rapides, les e-mails 55 % plus rapides, et lorsque l’audience est multipliée par 4, la hausse de la latence de bout en bout est passée de 186 % auparavant à respectivement 33 % et 60 %
• Avec Notification Factory et une API unique send_fanout_notifications, Patreon a standardisé le filtrage, les vérifications d’éligibilité et la génération des payloads, tout en suivant les timings par étape et les résultats par destinataire afin de simplifier l’exploitation et le débogage
• 10 équipes et plus de 30 ingénieurs ont migré plus de 200 notifications ; la génération de brouillons basée sur l’IA et une échéance claire fixée par la direction ont contribué à réduire le travail répétitif et la longue exploitation en parallèle

---

Les limites de scalabilité révélées par les grands créateurs

• Patreon envoie des milliards de notifications par an aux fans lorsqu’un créateur publie un post ou lance un livestream
• Avec le lancement de l’abonnement gratuit et la croissance de la plateforme, le nombre de fans par créateur a fortement augmenté, révélant début 2025 de sérieux goulots d’étranglement de performance, surtout chez les grands créateurs
• L’ancien système de notifications de posts reposait sur une tâche asynchrone unique qui récupérait tous les destinataires, les filtrait selon les paramètres de chaque utilisateur, générait le payload de chaque destinataire, puis le transmettait aux systèmes de livraison in-app, push et e-mail
• Pour les grands créateurs, une seule tâche devait prendre en charge la génération de millions de notifications, ce qui entraînait régulièrement des timeouts et rendait difficile la livraison fiable des notifications à une audience massive
• L’ancien flux présentait deux limites structurelles
  • Le coût de génération par destinataire était concentré dans une seule tâche asynchrone, ce qui empêchait la scalabilité horizontale et créait un plafond clair de débit
  • Le fil in-app, les push et les e-mails étaient fortement couplés, si bien qu’une panne sur un canal pouvait bloquer les autres
• Plusieurs équipes produit avaient construit des stratégies de scalabilité distinctes pour chaque notification à fort volume, ce qui résolvait les problèmes à court terme mais augmentait la complexité de la plateforme et compliquait le développement, l’exploitation et le débogage
• Patreon a décidé de conserver les systèmes de livraison existants, mais de placer devant eux une couche commune de fan-out pour fournir scalabilité horizontale, isolation des canaux et observabilité

Six contraintes de conception pour la plateforme de fan-out

• La nouvelle couche a été conçue pour diviser de grandes listes de destinataires en petits lots, générer les notifications par destinataire, puis les transmettre aux systèmes existants de fil in-app, push et e-mail
• La plateforme a appliqué les six exigences suivantes
  • Convivialité pour les développeurs : il ne devait pas être nécessaire de résoudre depuis zéro la scalabilité et la fiabilité pour chaque notification à fort volume, et la plateforme devait réduire les erreurs d’usage tout en prenant en charge des cas variés
  • Scalabilité horizontale : les listes de destinataires devaient être automatiquement divisées en petits lots et traitées de manière asynchrone
  • Isolation des canaux : le fil in-app, les push et les e-mails devaient s’exécuter indépendamment afin qu’une panne d’un canal ne se propage pas aux autres
  • Traitement prioritaire : les notifications sensibles au temps devaient utiliser des files et des pools de workers dédiés, séparés des notifications ordinaires
  • Observabilité : il devait être possible d’examiner les résultats du filtrage et de la livraison, et de mesurer la latence sur tout le cycle de vie d’une notification
  • Extensibilité : de futures fonctionnalités, comme la génération de listes de destinataires, devaient pouvoir être ajoutées sans autre refactorisation massive

Séparer la logique métier avec Notification Factory

• Patreon a introduit l’abstraction Notification Factory afin de séparer l’orchestration de la plateforme de la logique métier propre à chaque notification
• Chaque factory sert de plan de traitement d’une notification et définit les éléments suivants
  • La priorité de traitement
  • Les paramètres de notification à appliquer
  • La méthode de filtrage des destinataires
  • Les vérifications d’éligibilité propres à la notification
  • La façon de générer les payloads pour chaque canal
• Ce pattern s’appuie sur le moteur de tâches distribuées interne de Patreon et en partage plusieurs concepts
• Le modèle Notification définit les arguments de tâche contenant les données propres à une notification donnée, mais partagées par tous les destinataires
• La sous-classe BaseNotificationFactory associée agit comme un gestionnaire de tâche et contient la configuration et les méthodes permettant de filtrer les destinataires et de générer les notifications
• Pour que les tâches de fan-out, qui ne reçoivent que des payloads de notification sérialisés, puissent retrouver la logique métier à exécuter, Patreon utilise un registre qui associe chaque modèle Notification à la classe de factory correspondante
• Il fallait prendre en charge divers types de notifications tout en évitant les erreurs d’implémentation fréquentes et les requêtes de données inefficaces
  • Comme Patreon possède plusieurs types d’enregistrements utilisateur et méthodes de filtrage, l’interface des destinataires a été généralisée
  • Des hooks clairs permettent d’implémenter les paramètres utilisateur et les vérifications d’éligibilité propres à chaque notification

Une API unique et un fan-out en deux étapes

• Auparavant, chaque canal utilisait une API d’envoi distincte, ce qui pouvait faire diverger les flux in-app, push et e-mail, et obligeait les équipes produit à penser trop tôt aux comportements spécifiques à chaque canal
• Après la refonte, le point d’entrée a été unifié dans une API unique, send_fanout_notifications
  • L’appelant fournit le payload de notification, la liste des destinataires et un timestamp servant à mesurer le délai de livraison
  • L’API trouve la factory de la notification, détermine la taille des lots et la priorité, puis distribue indépendamment les tâches par canal
  • Une panne ou un retard sur un canal ne bloque pas les autres
• La première étape prend en charge la scalabilité de la génération des notifications
  • La liste complète des destinataires est découpée en petits lots
  • Chaque lot est traité par une tâche FanoutNotifications
  • La tâche filtre les destinataires, exécute les vérifications d’éligibilité propres à la notification, puis génère les payloads par canal via Notification Factory
• La deuxième étape prend en charge la scalabilité du transfert vers la livraison
  • Les notifications générées sont à nouveau fan-out vers des tâches de livraison dédiées au fil in-app, aux push et aux e-mails
• Au cœur du système, le gestionnaire de tâches FanoutNotifications se situe entre l’API et les systèmes existants de livraison par canal, transformant une immense tâche unique en de nombreuses petites tâches traitables indépendamment

Observabilité et débogage au niveau du destinataire

• Une notification peut échouer ou être ignorée pour de nombreuses raisons, par exemple si l’utilisateur a désactivé un paramètre, ne passe pas une vérification d’éligibilité ou ne peut pas être joint par e-mail
• Dans l’ancienne plateforme, vérifier le résultat de traitement d’une notification donnée nécessitait de combiner logs et données de plusieurs systèmes ; il n’existait pas non plus de traçage complet de l’exécution par destinataire, si bien qu’une enquête pouvait prendre des heures
• La nouvelle plateforme est conçue pour répondre aux questions suivantes
  • Combien de temps l’envoi de la notification a pris
  • Quelle était la taille de la liste initiale de destinataires
  • Combien de personnes ont été filtrées, et pour quelles raisons
  • Combien d’envois ont réussi par canal
  • Pourquoi un utilisateur donné a reçu ou non une notification donnée
• Patreon a introduit un modèle de données de timing et de journalisation transmis à l’ensemble de la plateforme
  • Des timestamps sont enregistrés à chaque étape du flux de notification
  • Des métriques et des événements sont générés à la fois pour les résultats agrégés et pour les résultats par destinataire
  • Les développeurs peuvent ajouter des attributs de logging afin d’inclure les entités liées dans les traces d’exécution et les événements
• Avec l’amélioration de l’observabilité, des alertes, des dashboards et des outils de débogage, les ingénieurs produit et les équipes support peuvent enquêter sur davantage de problèmes sans dépendre des ingénieurs plateforme

Migration de plus de 200 notifications

• Comme le pattern Notification Factory changeait la manière même de développer et maintenir les notifications, une simple transformation de code automatisée (codemod) ne suffisait pas pour migrer
• Il fallait préserver exactement la logique métier, les dépendances de données, les règles d’éligibilité et les comportements par canal de chaque notification
• Patreon a construit une compétence IA à partir de la documentation de migration et de PR exemplaires de migrations manuelles
  • Les développeurs pouvaient exécuter /migrate-notif-fanout <notif_name> pour générer un premier résultat de migration
  • Cela s’est révélé efficace pour les tâches répétitives comme la création du modèle de notification, l’association de la factory, la modification des points d’appel et l’application des patterns de la plateforme
• L’IA pouvait manquer une logique métier subtile, halluciner ou produire du code dupliqué nécessitant du nettoyage ; elle n’a donc pas remplacé le jugement des ingénieurs
• Plus de 200 notifications ont été migrées, et grâce à une collaboration à grande échelle incluant l’usage de l’IA, les 80 % restants ont été terminés en 6 semaines

Gains de performance et impact sur le développement produit

• En déplaçant la génération des notifications par destinataire vers des tâches capables de scaler horizontalement, Patreon peut désormais générer de manière fiable des millions de notifications pour un seul créateur, sans timeout
• Les performances des notifications à fort volume des grands créateurs se sont nettement améliorées
  • Les notifications push et du fil in-app sont devenues 80 % plus rapides
  • Les notifications e-mail sont devenues 55 % plus rapides
  • Lorsque l’audience est multipliée par 4, la latence de bout en bout des push et du fil in-app augmente de 33 %, et celle des e-mails de 60 %
  • Dans les mêmes conditions, la hausse de latence de l’ancienne plateforme était de 186 %
• Les équipes produit n’ont plus besoin de concevoir une solution de scalabilité distincte pour chaque notification à fort volume, et la vitesse de développement s’est également améliorée
• La nouvelle plateforme a soutenu des lancements majeurs de 2025, comme Lives, Quips, et l’acquisition de grands créateurs
• Sans la refonte par fan-out, ces lancements auraient rencontré les goulots d’étranglement existants et auraient exigé du temps d’ingénierie supplémentaire pour créer des solutions ponctuelles de scalabilité
• Les métriques de timing par étape permettent d’identifier où le temps est consommé et d’ajuster l’infrastructure selon l’équilibre recherché entre vitesse et coût

Neuf mois d’exploitation en parallèle et d’alignement organisationnel

• La partie la plus difficile a été de modifier un système legacy en production tout en coordonnant la migration entre plusieurs équipes
• Pendant 9 mois, deux systèmes de notifications ont fonctionné en parallèle
  • Chaque changement de plateforme devait être compatible à la fois avec l’ancien chemin et le nouveau chemin de fan-out
  • La surface susceptible de contenir des bugs et des incidents s’est élargie, et plus la migration durait, plus le risque opérationnel augmentait
  • Plusieurs petits incidents dus à des problèmes de compatibilité ont renforcé la nécessité de terminer la migration rapidement et en sécurité
• Au départ, Patreon a adopté une approche ascendante où chaque équipe produit priorisait elle-même ses migrations de notifications
  • En 6 mois, seulement environ 20 % avaient été migrées
  • Le rythme est resté lent, car le travail passait derrière les roadmaps produit et les autres priorités d’équipe
• Après que la direction engineering s’est alignée sur une finalisation au 1er trimestre 2026 et a fixé une échéance claire ainsi qu’une priorité à l’échelle de l’entreprise, les migrations restantes ont été terminées en 6 semaines
• Au total, 10 équipes et plus de 30 ingénieurs ont participé
  • Un tracker Notion et de l’automatisation ont servi à gérer l’avancement
  • Les parties prenantes ont été tenues informées fréquemment et le travail a été réparti entre plusieurs équipes
  • L’équipe plateforme a réalisé environ la moitié des migrations avant de confier le déploiement et le nettoyage aux équipes propriétaires des notifications
  • La charge a été distribuée afin d’éviter qu’elle ne se concentre sur les équipes possédant beaucoup de notifications
• Patreon a organisé une semaine de migration des notifications, avec office hours, leaderboard, récompenses et happy hour, afin d’accélérer l’avancement et de célébrer la finalisation
• Une marge a été prévue en terminant la passation 2 semaines avant l’échéance globale
  • Elle a permis d’aider les équipes ayant besoin de support supplémentaire et de rechercher les tâches manquantes dans le codebase
  • La dernière vérification a révélé 4 nouvelles migrations nécessaires et plusieurs éléments inachevés, finalisés avec seulement un faible impact sur le calendrier

Enseignements d’une migration de plateforme à grande échelle

• Sans priorité explicite, les migrations impliquant plusieurs équipes entrent en concurrence avec les roadmaps de chaque équipe et sont facilement repoussées
  • Cela se voit particulièrement dans la longue traîne des notifications à faible volume, où l’effet de scalabilité est moins évident
  • L’alignement de la direction, une priorité partagée et une échéance claire ont été essentiels pour terminer la migration dans un délai raisonnable

• Le travail de plateforme ne s’arrête pas à l’API

  • Auparavant, enquêter sur les questions de notifications et les problèmes de livraison d’autres équipes représentait une part importante de l’astreinte des ingénieurs plateforme
  • Il faut améliorer en même temps l’observabilité, les alertes, les dashboards et les outils de débogage pour que les équipes produit et support puissent enquêter de manière autonome et réduire la charge d’astreinte de la plateforme
  • Il faut tenir compte non seulement du goulot d’étranglement actuel, mais aussi du prochain goulot d’étranglement
  • Un seul projet ne pouvait pas résoudre tous les problèmes de scalabilité des notifications
  • Concevoir la plateforme pour accueillir de futures fonctionnalités réduit la probabilité de devoir mener une nouvelle refactorisation massive lorsque le volume de notifications augmentera

Prochain goulot d’étranglement et plans futurs

• La génération des notifications a été rendue scalable, mais le prochain goulot d’étranglement est la génération des listes de destinataires
• À mesure que les audiences ciblées par les notifications continuent de croître, interroger efficacement des millions de destinataires deviendra de plus en plus important
• Patreon prévoit d’intégrer la génération des listes de destinataires dans Notification Factory afin que la plateforme prenne en charge une plus grande part du flux de notifications de bout en bout
• Les paramètres de notification seront également améliorés, côté développeurs comme côté fans
  • Les développeurs seront aidés à créer et gérer plus facilement de nouveaux paramètres
  • Les fans pourront plus facilement comprendre et contrôler leurs préférences de notification