Patreon ने fanout के ज़रिए अपने notification system को कैसे scale किया

• सालाना अरबों notifications संभालने वाला 13 साल पुराना system तब timeout से टकराने लगा जब एक बड़े creator के लिए ही लाखों notifications बनने लगे, इसलिए Patreon ने इसे per-recipient notifications को पहले से generate करने वाली fanout layer के साथ फिर से डिज़ाइन किया
• recipient list को छोटे batches में बाँटकर और in-app feed, push, email को स्वतंत्र रूप से process करने वाला 2-stage fanout लागू किया गया, जिससे horizontal scalability और channel failure isolation मिला
• बड़े creators के लिए push और in-app feed 80%, और email 55% तेज़ हो गए, जबकि audience 4 गुना बढ़ने पर end-to-end latency बढ़ोतरी भी पहले के 186% से घटकर क्रमशः 33% और 60% रह गई
• Notification Factory और एक single API send_fanout_notifications के साथ filtering, eligibility checks, payload generation को standardize किया गया, और step-wise timing तथा recipient-level results को track करके operations और debugging को आसान बनाया गया
• 10 teams और 30 से अधिक engineers ने 200 से ज़्यादा notifications migrate किए, और AI-आधारित draft generation तथा leadership द्वारा तय स्पष्ट deadline ने दोहराए जाने वाले काम और लंबे parallel operation को कम करने में मदद की

---

बड़े creators ने scaling limits को उजागर किया

• Patreon तब fans को सालाना अरबों notifications भेजता है जब creators posts publish करते हैं या livestream शुरू करते हैं
• free membership launch और growth के साथ प्रति creator fans की संख्या तेज़ी से बढ़ी, और 2025 की शुरुआत में बड़े creators के इर्द-गिर्द गंभीर performance bottlenecks सामने आए
• मौजूदा post notification flow में एक asynchronous job पूरी recipient list लाती थी, user-specific settings के आधार पर filter करती थी, हर recipient के लिए payload बनाती थी, और फिर उसे in-app feed, push, email delivery systems को सौंप देती थी
• बड़े creators के मामले में एक single job को लाखों notifications generate करने पड़ते थे, जिससे लगातार timeouts होने लगे और बड़े audience तक notifications को भरोसेमंद तरीके से पहुँचाना मुश्किल हो गया
• पुराने flow में दो structural limitations थीं
  • per-recipient generation cost एक ही asynchronous job में केंद्रित थी, इसलिए horizontal scaling संभव नहीं थी और throughput की एक स्पष्ट upper limit बन जाती थी
  • in-app feed, push, email काफ़ी tightly coupled थे, इसलिए एक channel की failure दूसरे channels को भी रोक सकती थी
• कई product teams ने high-volume notifications के लिए अलग-अलग scaling approaches बनाकर short-term समस्याएँ तो हल कर लीं, लेकिन इससे platform complexity बढ़ी और development, operations, debugging और कठिन हो गए
• फैसला यह हुआ कि मौजूदा delivery systems को बनाए रखते हुए उनके आगे एक common fanout layer रखी जाए, जो horizontal scalability, channel isolation और observability दे

fanout platform के छह design requirements

• नई layer को इस तरह डिज़ाइन किया गया कि वह बड़ी recipient list को छोटे batches में बाँटे, per-recipient notifications generate करे, और फिर उन्हें मौजूदा in-app feed, push, email systems तक पहुँचाए
• platform पर ये छह requirements लागू की गईं
  • developer friendliness: हर high-volume notification के लिए scalability और reliability को शुरू से हल करने की ज़रूरत नहीं होनी चाहिए, और platform को usage mistakes घटाते हुए अलग-अलग cases support करने चाहिए
  • horizontal scalability: recipient list को अपने-आप छोटे batches में बाँटकर asynchronously process किया जाना चाहिए
  • channel isolation: in-app feed, push, email को independently run होना चाहिए ताकि एक channel की समस्या दूसरे तक न फैले
  • priority handling: time-sensitive notifications को dedicated queues और worker pools के साथ general notifications से अलग रखना चाहिए
  • observability: filtering और delivery results की जाँच हो सके, और पूरे notification lifecycle की latency मापी जा सके
  • extensibility: recipient list generation जैसे future features को किसी और बड़े refactoring के बिना जोड़ा जा सके

Notification Factory के साथ business logic को अलग करना

• platform orchestration और notification-specific business logic को अलग करने के लिए Notification Factory abstraction लाई गई
• हर factory notification processing की blueprint की तरह इन चीज़ों को define करती है
  • processing priority
  • लागू होने वाली notification settings
  • recipient filtering का तरीका
  • notification-specific eligibility checks
  • channel-specific payload generation का तरीका
• यह pattern Patreon के अपने distributed task engine पर आधारित है और कई concepts साझा करता है
• Notification model उन job arguments को define करता है जिनमें किसी specific notification के लिए unique लेकिन सभी recipients द्वारा shared data होता है
• उससे जुड़ी BaseNotificationFactory subclass job handler की तरह काम करती है, जिसमें recipients को filter करने और notifications generate करने के configurations और methods शामिल होते हैं
• ताकि serialized notification payloads ही पाने वाले fanout jobs सही business logic ढूँढ सकें, हर Notification model को उसके factory class से map करने के लिए एक registry इस्तेमाल की गई
• platform को अलग-अलग notification types support करने के साथ-साथ आम implementation mistakes और inefficient data lookups को भी रोकना था
  • Patreon में कई तरह के user record types और filtering methods हैं, इसलिए recipient interface को generalized रखा गया
  • user settings और notification-specific eligibility checks लागू करने के लिए साफ़ hooks दिए गए

single API और 2-stage fanout

• पहले हर channel के लिए अलग sending APIs थीं, इसलिए in-app feed, push, email flows एक-दूसरे से अलग हो सकते थे, और product teams को बहुत जल्दी channel-specific behavior के बारे में सोचना पड़ता था
• redesign के बाद entry point को एक single API send_fanout_notifications में समेकित किया गया
  • caller notification payload, recipient list, और delivery latency मापने के लिए इस्तेमाल होने वाला timestamp देता है
  • API उस notification की factory ढूँढती है, batch size और priority तय करती है, और फिर channel-specific jobs को independently distribute करती है
  • एक channel की failure या delay दूसरे channels को नहीं रोकती
• पहला stage notification generation scaling के लिए है
  • पूरी recipient list को छोटे batches में बाँटा जाता है
  • हर batch को FanoutNotifications job process करती है
  • job recipients को filter करती है, notification-specific eligibility checks चलाती है, और Notification Factory के ज़रिए channel-specific payloads generate करती है
• दूसरा stage delivery handoff scaling संभालता है
  • generated notifications को फिर in-app feed, push, email-specific delivery jobs में दोबारा fanout किया जाता है
• मुख्य FanoutNotifications job handler API और मौजूदा channel delivery systems के बीच बैठता है, और एक बहुत बड़े job को कई छोटे jobs में बदल देता है जिन्हें independently process किया जा सकता है

recipient-level observability और debugging

• notifications कई कारणों से fail या skip हो सकती हैं, जैसे user ने setting disable कर दी हो, eligibility check पास न किया हो, या email address पर deliver न किया जा सके
• पुराने platform में किसी specific notification के processing result को समझने के लिए कई systems के logs और data को जोड़ना पड़ता था, और comprehensive recipient-level execution tracing न होने से investigation में घंटों लग सकते थे
• नया platform इस तरह डिज़ाइन किया गया कि वह इन सवालों का जवाब दे सके
  • notification भेजने में कितना समय लगा
  • initial recipient list कितनी बड़ी थी
  • कितने लोग और किन कारणों से filter हुए
  • channel के हिसाब से कितनी deliveries सफल रहीं
  • किसी specific user को कोई specific notification क्यों मिला या क्यों नहीं मिला
• पूरे platform में pass होने वाला timing और logging data model लागू किया गया
  • notification flow के हर stage पर timestamps रिकॉर्ड किए जाते हैं
  • aggregate results और recipient-level results दोनों के लिए metrics और events generate किए जाते हैं
  • developers logging properties जोड़कर संबंधित entities को execution traces और events में शामिल कर सकते हैं
• observability, alerting, dashboards, और debugging tools बेहतर होने से product engineers और support teams अब platform engineers पर निर्भर हुए बिना ज़्यादा समस्याओं की जाँच कर सकते हैं

200 से ज़्यादा notifications का migration

• Notification Factory pattern ने notifications को develop और maintain करने का तरीका ही बदल दिया, इसलिए इसे सिर्फ़ code transformation tool (codemod) से migrate नहीं किया जा सकता था
• हर notification का business logic, data dependencies, eligibility rules, और channel-specific behavior जस का तस बनाए रखना ज़रूरी था
• migration docs और example manual migration PRs के आधार पर एक AI skill बनाई गई
  • developers /migrate-notif-fanout <notif_name> चलाकर first-pass migration result generate कर सकते थे
  • notification model creation, factory wiring, call-site updates, और platform patterns लागू करने जैसे दोहराए जाने वाले कामों में यह असरदार रही
• AI subtle business logic miss कर सकती थी, hallucinate कर सकती थी, और cleanup माँगने वाला duplicate code बना सकती थी, इसलिए उसने engineers के judgment की जगह नहीं ली
• 200 से ज़्यादा notifications migrate की गईं, और AI के उपयोग सहित बड़े पैमाने के collaboration से बाकी 80% सिर्फ़ 6 हफ़्तों में पूरे किए गए

performance improvements और product development पर असर

• per-recipient notification generation को horizontally scalable jobs में ले जाकर, अब एक creator के लिए लाखों notifications बिना timeout के भरोसेमंद तरीके से generate की जा सकती हैं
• बड़े creators के high-volume notifications की performance में बड़ा सुधार हुआ
  • push और in-app feed notifications 80% तेज़ हो गए
  • email notifications 55% तेज़ हो गईं
  • audience 4 गुना बढ़ने पर push और in-app feed की end-to-end latency 33% बढ़ती है, और email की 60%
  • यही बढ़ोतरी पुराने platform में 186% थी
• product teams को अब हर high-volume notification के लिए अलग scaling solution डिज़ाइन करने की ज़रूरत नहीं रही, और development speed भी बेहतर हुई
• नया platform 2025 के Lives, Quips, और बड़े creators को onboard करने जैसे प्रमुख launches को support करता है
• अगर fanout redesign न होता, तो ये launches पुराने bottlenecks से टकराते और one-off scaling solutions बनाने के लिए अतिरिक्त engineering time चाहिए होता
• stage-wise timing metrics से यह समझना आसान हुआ कि समय कहाँ खर्च हो रहा है, और speed तथा cost के संतुलन के अनुसार infrastructure को tune किया जा सकता है

9 महीने का parallel operation और organizational coordination

• production में चल रहे legacy system को बदलते हुए कई teams के migrations को coordinate करना सबसे कठिन हिस्सा था
• 9 महीनों तक दो notification systems parallel में चलाए गए
  • platform में हर बदलाव को पुराने path और नए fanout path दोनों के साथ compatible होना पड़ता था
  • bugs और incidents की संभावित सीमा बढ़ गई, और migration जितना लंबा खिंचता गया, operational risk भी उतना बढ़ा
  • compatibility issues के कारण कुछ छोटे incidents हुए, जिससे migration को जल्दी और सुरक्षित रूप से पूरा करने की ज़रूरत और बढ़ गई
• शुरुआत में bottom-up approach अपनाई गई, जहाँ हर product team अपनी notification migration की priority खुद तय करती थी
  • 6 महीनों में केवल लगभग 20% ही migrate हो पाया
  • product roadmap और दूसरी team priorities के कारण progress धीमी रही
• engineering leadership ने 2026 की पहली तिमाही तक completion पर सहमति बनाई और स्पष्ट deadline तथा company-wide priority देने के बाद बाकी migrations 6 हफ़्तों में पूरी हो गईं
• पूरे प्रयास में 10 teams और 30 से अधिक engineers शामिल थे
  • progress को Notion tracker और automation से manage किया गया
  • stakeholders के साथ बार-बार communication किया गया और काम को कई teams में बाँटा गया
  • platform team ने लगभग आधे migrations किए, फिर deployment और cleanup notification-owning teams को सौंप दिया
  • workload को इस तरह बाँटा गया कि बहुत अधिक notifications वाली teams पर ज़्यादा दबाव न पड़े
• progress तेज़ करने और completion celebrate करने के लिए office hours, leaderboard, prizes, और happy hour के साथ notification migration week आयोजित किया गया
• कुल deadline से 2 हफ़्ते पहले handoff पूरा करके buffer time रखा गया
  • जिन teams को अतिरिक्त support चाहिए थी उनकी मदद की गई और codebase में छूटे हुए कामों की खोज की गई
  • अंतिम जाँच में 4 नए required migrations और कई अधूरे items मिले, लेकिन schedule पर सिर्फ़ मामूली असर पड़ा और काम पूरा हो गया

बड़े platform migrations से मिली सीख

• स्पष्ट priority के बिना कई teams में फैले migrations आसानी से हर team के roadmap से टकराकर पीछे चले जाते हैं
  • यह खासकर low-volume notifications के लंबे tail वाले हिस्से में अधिक साफ़ दिखा, जहाँ scaling impact कम स्पष्ट था
  • leadership alignment, shared priority, और clear deadline उचित समय के भीतर migration पूरी करने के लिए महत्वपूर्ण थे

• platform work API पर खत्म नहीं होता

  • पहले दूसरी teams के notification सवालों और delivery issues की जाँच platform engineer on-call work का बड़ा हिस्सा होती थी
  • observability, alerting, dashboards, और debugging tools को साथ में बेहतर बनाना ज़रूरी था ताकि product और support teams खुद से investigation कर सकें और platform on-call burden कम हो
  • सिर्फ़ मौजूदा bottleneck नहीं, अगले bottleneck को भी ध्यान में रखना चाहिए
  • एक ही project में सभी notification scaling problems हल नहीं की जा सकती थीं
  • future features को ध्यान में रखकर design करने से notification volume बढ़ने पर किसी और बड़े refactoring की ज़रूरत की संभावना कम होती है

अगला bottleneck और आगे की योजना

• notification generation को scale कर लिया गया है, लेकिन अगला bottleneck recipient list generation है
• notification audience बढ़ती रही तो लाखों recipients को efficiently query करना और भी महत्वपूर्ण होता जाएगा
• योजना यह है कि recipient list generation को Notification Factory में शामिल किया जाए ताकि platform end-to-end notification flow का और बड़ा हिस्सा संभाल सके
• notification settings में भी developers और fans दोनों के लिए सुधार किए जाएँगे
  • developers को नई settings बनाना और manage करना आसान बनाया जाएगा
  • fans के लिए notification preferences को समझना और control करना आसान किया जाएगा