Wie Patreon sein Benachrichtigungssystem mit Fan-out skaliert hat

• Das 13 Jahre alte System, das jährlich zig Milliarden Benachrichtigungen verarbeitet hatte, stieß an Timeouts, als es für einzelne große Creators Millionen von Benachrichtigungen erzeugen musste. Patreon gestaltete es daher mit einer Fan-out-Schicht neu, die Benachrichtigungen vorab pro Empfänger erstellt.
• Mit einem zweistufigen Fan-out, der Empfängerlisten in kleine Batches aufteilt und In-App-Feed, Push und E-Mail unabhängig verarbeitet, erreichte Patreon horizontale Skalierbarkeit und eine Isolierung von Kanalstörungen.
• Bei großen Creators wurden Push und In-App-Feed um 80 %, E-Mails um 55 % beschleunigt; außerdem sank beim Vervierfachen der Zielgruppe die Zunahme der End-to-End-Latenz von zuvor 186 % auf jeweils 33 % bzw. 60 %.
• Mit der Notification Factory und der einheitlichen API send_fanout_notifications wurden Filterung, Berechtigungsprüfungen und Payload-Erzeugung standardisiert; zugleich vereinfachten stufenweises Timing und empfängerbezogene Ergebnisse Betrieb und Debugging.
• 10 Teams und mehr als 30 Engineers migrierten über 200 Benachrichtigungen; KI-basierte Draft-Erstellung und ein von der Führung festgelegter klarer Stichtag halfen dabei, wiederkehrende Arbeit und einen langen Parallelbetrieb zu reduzieren.

---

Große Creators machten die Skalierungsgrenzen sichtbar

• Patreon sendet jährlich zig Milliarden Benachrichtigungen an Fans, wenn Creators Beiträge veröffentlichen oder Livestreams starten.
• Mit der Einführung kostenloser Mitgliedschaften und weiterem Wachstum stieg die Zahl der Fans pro Creator stark an, sodass Anfang 2025 vor allem bei großen Creators gravierende Performance-Engpässe sichtbar wurden.
• Bestehende Benachrichtigungen für Beiträge waren so aufgebaut, dass ein einzelner asynchroner Job alle Empfänger abrief, sie anhand nutzerspezifischer Einstellungen filterte, für jeden Empfänger den Payload erzeugte und ihn dann an die Zustellsysteme für In-App-Feed, Push und E-Mail übergab.
• Bei großen Creators war ein einzelner Job für die Erzeugung von Millionen Benachrichtigungen zuständig, was wiederholt zu Timeouts führte und eine zuverlässige Zustellung an große Zielgruppen erschwerte.
• Der bestehende Ablauf hatte zwei strukturelle Grenzen:
  • Die Kosten für die Erzeugung pro Empfänger konzentrierten sich in einem einzigen asynchronen Job, wodurch horizontale Skalierung unmöglich war und der Durchsatz eine klare Obergrenze hatte.
  • In-App-Feed, Push und E-Mail waren eng gekoppelt, sodass ein Fehler in einem Kanal auch andere Kanäle blockieren konnte.
• Mehrere Produktteams bauten für Benachrichtigungen mit hohem Volumen jeweils eigene Skalierungsansätze. Das löste kurzfristige Probleme, erhöhte aber die Plattformkomplexität und erschwerte Entwicklung, Betrieb und Debugging.
• Patreon entschied sich daher, die bestehenden Zustellsysteme beizubehalten, ihnen aber eine gemeinsame Fan-out-Schicht vorzuschalten, die horizontale Skalierbarkeit, Kanalisolierung und Observability bietet.

Sechs Designanforderungen an die Fan-out-Plattform

• Die neue Schicht wurde so entworfen, dass sie große Empfängerlisten in kleine Batches aufteilt, Benachrichtigungen pro Empfänger erzeugt und sie anschließend an die bestehenden Systeme für In-App-Feed, Push und E-Mail weiterleitet.
• Für die Plattform galten die folgenden sechs Anforderungen:
  • Entwicklerfreundlichkeit: Für jede Benachrichtigung mit hohem Volumen sollte Skalierbarkeit und Zuverlässigkeit nicht von Grund auf neu gelöst werden müssen; gleichzeitig sollte die Plattform unterschiedliche Anwendungsfälle unterstützen und Bedienfehler reduzieren.
  • Horizontale Skalierbarkeit: Empfängerlisten sollten automatisch in kleine Batches zerlegt und asynchron verarbeitet werden.
  • Kanalisolierung: In-App-Feed, Push und E-Mail sollten unabhängig ausgeführt werden, damit Ausfälle in einem Kanal nicht auf andere übergreifen.
  • Priorisierte Verarbeitung: Zeitkritische Benachrichtigungen sollten über dedizierte Queues und Worker-Pools getrennt von normalen Benachrichtigungen verarbeitet werden.
  • Observability: Filter- und Zustellergebnisse sollten untersuchbar sein, und die Latenz über den gesamten Lebenszyklus einer Benachrichtigung sollte messbar sein.
  • Erweiterbarkeit: Künftige Funktionen wie die Erzeugung von Empfängerlisten sollten ohne eine weitere große Refaktorierung ergänzt werden können.

Trennung der Business-Logik mit der Notification Factory

• Um Plattform-Orchestrierung und benachrichtigungsspezifische Business-Logik zu trennen, führte Patreon die Abstraktion Notification Factory ein.
• Jede Factory definiert als Blueprint für die Benachrichtigungsverarbeitung die folgenden Punkte:
  • Verarbeitungspriorität
  • Anzuwendende Benachrichtigungseinstellungen
  • Art der Empfängerfilterung
  • Benachrichtigungsspezifische Berechtigungsprüfung
  • Art der Payload-Erzeugung pro Kanal
• Dieses Muster basiert auf Patreons eigener Engine für verteilte Jobs und teilt mehrere Konzepte mit ihr.
• Das Notification-Modell definiert Job-Argumente, die für eine bestimmte Benachrichtigung eindeutig sind, aber von allen Empfängern gemeinsam genutzt werden.
• Die verknüpfte Unterklasse von BaseNotificationFactory fungiert als Job-Handler und enthält Konfigurationen und Methoden zum Filtern von Empfängern sowie zum Erzeugen von Benachrichtigungen.
• Damit Fan-out-Jobs, die nur serialisierte Benachrichtigungs-Payloads erhalten, die auszuführende Business-Logik finden können, verwendet Patreon ein Register, das jedes Notification-Modell der entsprechenden Factory-Klasse zuordnet.
• Gleichzeitig musste die Plattform verschiedene Benachrichtigungstypen unterstützen und häufige Implementierungsfehler sowie ineffiziente Datenabfragen verhindern.
  • Da Patreon mehrere Arten von User-Records und Filtermethoden hat, wurde die Empfängerschnittstelle verallgemeinert.
  • Es wurden klare Hooks bereitgestellt, mit denen sich Nutzereinstellungen und benachrichtigungsspezifische Berechtigungsprüfungen implementieren lassen.

Eine einheitliche API und zweistufiger Fan-out

• Früher nutzte jeder Kanal eigene Versand-APIs, sodass sich die Abläufe für In-App-Feed, Push und E-Mail unterscheiden konnten und Produktteams kanalbezogenes Verhalten schon sehr früh berücksichtigen mussten.
• Nach der Neugestaltung wurde der Einstiegspunkt in einer einheitlichen API, send_fanout_notifications, zusammengeführt.
  • Der aufrufende Code übergibt den Benachrichtigungs-Payload, die Empfängerliste und einen Zeitstempel zur Messung der Zustelllatenz.
  • Die API sucht die Factory für die jeweilige Benachrichtigung, bestimmt Batch-Größe und Priorität und verteilt dann kanalbezogene Jobs unabhängig voneinander.
  • Fehler oder Verzögerungen in einem Kanal blockieren die anderen nicht.
• Die erste Stufe skaliert die Erzeugung von Benachrichtigungen.
  • Die vollständige Empfängerliste wird in kleine Batches aufgeteilt.
  • Jeder Batch wird von einem FanoutNotifications-Job verarbeitet.
  • Der Job filtert Empfänger, führt benachrichtigungsspezifische Berechtigungsprüfungen aus und erzeugt mit der Notification Factory kanalbezogene Payloads.
• Die zweite Stufe skaliert die Übergabe an die Zustellung.
  • Die erzeugten Benachrichtigungen werden erneut an dedizierte Zustelljobs für In-App-Feed, Push und E-Mail aufgefächert.
• Der zentrale Job-Handler FanoutNotifications sitzt zwischen API und bestehenden kanalbezogenen Zustellsystemen und ersetzt einen einzigen gigantischen Job durch viele kleine Jobs, die unabhängig verarbeitet werden können.

Observability und Debugging auf Empfängerebene

• Benachrichtigungen können aus vielen Gründen fehlschlagen oder übersprungen werden, etwa weil Nutzer Einstellungen deaktiviert haben, eine Berechtigungsprüfung nicht bestanden wurde oder keine Zustellung an eine E-Mail-Adresse möglich ist.
• In der bisherigen Plattform musste man zur Prüfung des Verarbeitungsergebnisses einer bestimmten Benachrichtigung Logs und Daten aus mehreren Systemen zusammenführen; da es kein umfassendes empfängerbezogenes Execution-Tracking gab, konnten Untersuchungen Stunden dauern.
• Die neue Plattform wurde so entworfen, dass sie folgende Fragen beantworten kann:
  • Wie lange hat der Versand der Benachrichtigung gedauert?
  • Wie groß war die ursprüngliche Empfängerliste?
  • Wie viele Empfänger wurden aus welchen Gründen gefiltert?
  • Wie viele Benachrichtigungen wurden pro Kanal erfolgreich versendet?
  • Warum hat ein bestimmter Nutzer eine bestimmte Benachrichtigung erhalten oder nicht erhalten?
• Patreon führte ein plattformweites Datenmodell für Timing und Logging ein.
  • In jeder Phase des Benachrichtigungsflusses werden Zeitstempel erfasst.
  • Sowohl für aggregierte Ergebnisse als auch für empfängerbezogene Resultate werden Metriken und Events erzeugt.
  • Entwickler können Logging-Eigenschaften anhängen, damit relevante Entitäten in Execution-Traces und Events enthalten sind.
• Durch Verbesserungen bei Observability, Alerts, Dashboards und Debugging-Tools können Produkt-Engineers und Support-Teams nun mehr Probleme untersuchen, ohne auf Plattform-Engineers angewiesen zu sein.

Migration von mehr als 200 Benachrichtigungen

• Das Notification-Factory-Muster veränderte die Art und Weise, wie Benachrichtigungen entwickelt und gepflegt werden, grundlegend, weshalb die Migration nicht allein mit einem einfachen Codemod möglich war.
• Die Business-Logik, Datenabhängigkeiten, Berechtigungsregeln und das kanalbezogene Verhalten jeder Benachrichtigung mussten unverändert erhalten bleiben.
• Auf Basis von Migrationsdokumentation und vorbildlichen manuell erstellten Migrations-PRs wurde ein KI-Skill aufgebaut.
  • Entwickler konnten mit /migrate-notif-fanout <notif_name> ein erstes Migrationsergebnis erzeugen.
  • Das war besonders wirksam für wiederkehrende Aufgaben wie das Erstellen von Notification-Modellen, das Verknüpfen von Factories, das Anpassen von Aufrufstellen und das Anwenden von Plattformmustern.
• KI ersetzte die Beurteilung durch Engineers nicht, da sie subtile Business-Logik übersehen, halluzinieren und bereinigungsbedürftigen doppelten Code erzeugen konnte.
• Mehr als 200 Benachrichtigungen wurden migriert; durch groß angelegte Zusammenarbeit einschließlich KI-Unterstützung wurden die verbleibenden 80 % in nur 6 Wochen abgeschlossen.

Performance-Gewinne und Auswirkungen auf die Produktentwicklung

• Durch die Verlagerung der empfängerbezogenen Benachrichtigungserzeugung in horizontal skalierbare Jobs konnte Patreon nun Millionen von Benachrichtigungen pro Creator zuverlässig und ohne Timeouts erzeugen.
• Die Performance von Benachrichtigungen mit hohem Volumen bei großen Creators verbesserte sich deutlich.
  • Push- und In-App-Feed-Benachrichtigungen wurden 80 % schneller.
  • E-Mail-Benachrichtigungen wurden 55 % schneller.
  • Wenn die Zielgruppe um das Vierfache wächst, steigt die End-to-End-Latenz bei Push und In-App-Feed um 33 %, bei E-Mail um 60 %.
  • Unter denselben Bedingungen lag die Latenzzunahme auf der alten Plattform bei 186 %.
• Produktteams mussten nicht länger für jede Benachrichtigung mit hohem Volumen eine eigene Skalierungslösung entwerfen, was auch die Entwicklungsgeschwindigkeit verbesserte.
• Die neue Plattform unterstützte wichtige Launches im Jahr 2025 wie Lives, Quips und die Gewinnung großer Creators.
• Ohne das Fan-out-Redesign wären diese Launches an den bestehenden Engpässen gescheitert und hätten zusätzliche Engineering-Zeit für einmalige Skalierungslösungen erfordert.
• Mit Timing-Metriken pro Phase kann Patreon nun erkennen, wo Zeit verbraucht wird, und die Infrastruktur passend zur Balance zwischen Geschwindigkeit und Kosten anpassen.

Neun Monate Parallelbetrieb und organisatorische Abstimmung

• Die schwierigste Aufgabe war es, Änderungen an einem laufenden Legacy-System vorzunehmen und gleichzeitig Migrationen über mehrere Teams hinweg zu koordinieren.
• Über 9 Monate liefen zwei Benachrichtigungssysteme parallel.
  • Alle Plattformänderungen mussten sowohl mit dem alten Pfad als auch mit dem neuen Fan-out-Pfad kompatibel sein.
  • Der mögliche Bereich für Bugs und Ausfälle wurde größer, und mit zunehmender Migrationsdauer stieg auch das Betriebsrisiko.
  • Wegen Kompatibilitätsproblemen kam es einige Male zu kleineren Störungen, was die Notwendigkeit verstärkte, die Migration schnell und sicher abzuschließen.
• Anfangs setzte Patreon auf einen Bottom-up-Ansatz, bei dem jedes Produktteam die Priorität seiner eigenen Benachrichtigungsmigration selbst festlegte.
  • In 6 Monaten wurden so nur etwa 20 % migriert.
  • Da Produkt-Roadmaps und andere Teamprioritäten dazwischenkamen, war der Fortschritt langsam.
• Nachdem sich das Engineering-Leadership auf einen Abschluss im 1. Quartal 2026 geeinigt und eine klare Frist sowie unternehmensweite Priorität gesetzt hatte, wurde die restliche Migration in nur 6 Wochen abgeschlossen.
• Insgesamt waren 10 Teams und mehr als 30 Engineers an der Arbeit beteiligt.
  • Ein Notion-Tracker und Automatisierungen dienten zur Steuerung des Fortschritts.
  • Mit Stakeholdern wurde häufig kommuniziert und die Arbeit auf mehrere Teams verteilt.
  • Das Plattformteam übernahm rund die Hälfte der Migrationen und übergab anschließend Deployments und Cleanup an die Teams, denen die Benachrichtigungen gehörten.
  • Die Arbeitslast wurde verteilt, damit Teams mit vielen Benachrichtigungen nicht überlastet wurden.
• Um den Fortschritt zu beschleunigen und den Abschluss zu feiern, veranstaltete Patreon eine Woche der Benachrichtigungsmigration mit Office Hours, Leaderboard, Preisen und Happy Hour.
• Vor dem Gesamtabgabetermin blieb ein Puffer von 2 Wochen, da die Übergabe früher abgeschlossen wurde.
  • In dieser Zeit wurden Teams mit zusätzlichem Unterstützungsbedarf geholfen und im Codebestand nach übersehenen Aufgaben gesucht.
  • Bei der finalen Prüfung wurden vier weitere erforderliche Migrationen und mehrere unvollständige Punkte entdeckt, die nur geringe Auswirkungen auf den Zeitplan hatten und noch abgeschlossen werden konnten.

Erkenntnisse aus einer großen Plattformmigration

• Ohne explizite Priorisierung werden teamübergreifende Migrationen leicht von den Roadmaps einzelner Teams verdrängt.
  • Das zeigte sich besonders im langen Nachlauf weniger volumenstarker Benachrichtigungen, bei denen der Skalierungseffekt weniger deutlich war.
  • Abstimmung mit dem Leadership, gemeinsame Prioritäten und eine klare Frist waren entscheidend, um die Migration in einem vernünftigen Zeitraum abzuschließen.

• Plattformarbeit endet nicht bei der API

  • Zuvor machte die Untersuchung von Benachrichtigungsfragen anderer Teams und Zustellproblemen einen beträchtlichen Teil des Plattform-Oncalls aus.
  • Nur wenn auch Observability, Alerts, Dashboards und Debugging-Tools verbessert werden, können Produkt- und Support-Teams Probleme eigenständig untersuchen und die Oncall-Last des Plattformteams sinkt.
  • Nicht nur der aktuelle Engpass, sondern auch der nächste Engpass muss berücksichtigt werden.
  • Ein einzelnes Projekt konnte nicht alle Skalierungsprobleme bei Benachrichtigungen lösen.
  • Durch ein Design, das zukünftige Funktionen aufnehmen kann, sinkt die Wahrscheinlichkeit, bei weiter wachsendem Benachrichtigungsvolumen erneut eine große Refaktorierung zu benötigen.

Der nächste Engpass und die weiteren Pläne

• Die Erzeugung von Benachrichtigungen wurde skaliert, doch der nächste Engpass ist die Erzeugung der Empfängerliste.
• Wenn die Zahl der Ziele weiter wächst, wird die effiziente Abfrage von Millionen Empfängern immer wichtiger.
• Patreon plant, die Erzeugung der Empfängerliste in die Notification Factory aufzunehmen, damit die Plattform den End-to-End-Benachrichtigungsfluss noch stärker übernimmt.
• Auch die Benachrichtigungseinstellungen sollen sowohl für Entwickler als auch für Fans verbessert werden.
  • Entwickler sollen neue Einstellungen leichter erstellen und verwalten können.
  • Fans sollen ihre Benachrichtigungseinstellungen leichter verstehen und steuern können.