Patreon, bildirim sistemini fanout ile nasıl ölçekledi

• Yılda milyarlarca bildirimi işlemiş 13 yıllık sistem, tek bir büyük içerik üretici için milyonlarca bildirim üretirken timeout’lara takıldı; Patreon bunu alıcı başına bildirimleri önceden üreten bir fanout katmanıyla yeniden tasarladı
• Alıcı listesini küçük batch’lere bölüp uygulama içi feed, push ve e-postayı bağımsız işleyen 2 aşamalı fanout uygulayarak yatay ölçeklenebilirlik ve kanal arızası izolasyonu sağladı
• Büyük içerik üreticilerde push ve uygulama içi feed %80, e-posta ise %55 hızlandı; kitle 4 kat büyüdüğünde uçtan uca gecikme artışı da önceki %186’dan sırasıyla %33 ve %60’a düştü
• Notification Factory ve tek API send_fanout_notifications ile filtreleme, uygunluk kontrolleri ve payload üretimini standartlaştırdı; aşama bazlı zamanlamayı ve alıcı başına sonuçları izleyerek operasyonu ve hata ayıklamayı sadeleştirdi
• 10 ekip ve 30’dan fazla mühendis 200’den fazla bildirimi taşıdı; yapay zeka tabanlı taslak oluşturma ve liderliğin belirlediği net son tarihler, tekrarlı işleri ve uzun süreli paralel çalışmayı azaltmaya katkı sağladı

---

Büyük içerik üreticilerin ortaya çıkardığı ölçek sınırı

• Patreon, içerik üreticiler bir gönderi yayımladığında veya livestream başlattığında hayranlara yılda milyarlarca bildirim gönderiyor
• Ücretsiz üyeliklerin çıkışı ve büyümeyle içerik üretici başına hayran sayısı hızla artınca, 2025’in başlarında özellikle büyük içerik üreticilerde ciddi performans darboğazları ortaya çıktı
• Mevcut gönderi bildirimi akışı, tek bir asenkron işin tüm alıcıları alıp kullanıcı bazlı ayarlara göre filtrelemesi, her alıcının payload’unu üretmesi ve ardından uygulama içi feed, push ve e-posta teslim sistemlerine devretmesi şeklindeydi
• Büyük içerik üreticilerde tek bir iş milyonlarca bildirim üretimini üstlenince sürekli timeout’lar oluştu ve bildirimleri büyük kitlelere güvenilir şekilde ulaştırmak zorlaştı
• Mevcut akışın iki yapısal sınırı vardı
  • Alıcı başına üretim maliyeti tek bir asenkron işte toplandığı için yatay ölçekleme mümkün değildi ve throughput için net bir üst sınır oluşuyordu
  • Uygulama içi feed, push ve e-posta sıkı bağlıydı; bir kanaldaki hata diğer kanalları da durdurabiliyordu
• Birden çok ürün ekibi, yüksek hacimli her bildirim için ayrı ölçekleme yöntemleri oluşturarak kısa vadeli sorunları çözdü; ancak platform karmaşıklığı arttı, geliştirme, operasyon ve hata ayıklama zorlaştı
• Mevcut teslim sistemini koruyup önüne ortak bir fanout katmanı yerleştirerek yatay ölçeklenebilirlik, kanal izolasyonu ve gözlemlenebilirlik sağlamaya karar verildi

Fanout platformunun altı tasarım koşulu

• Yeni katman, büyük alıcı listelerini küçük batch’lere ayırmak, alıcı başına bildirim üretmek ve bunları mevcut uygulama içi feed, push ve e-posta sistemlerine aktarmak üzere tasarlandı
• Platforma şu altı gereksinim uygulandı
  • Geliştirici dostu olma: Her yüksek hacimli bildirim için ölçeklenebilirlik ve güvenilirlik sorunlarını sıfırdan çözmek gerekmemeli; kullanım hataları azaltılırken farklı kullanım senaryoları desteklenmeli
  • Yatay ölçeklenebilirlik: Alıcı listeleri otomatik olarak küçük batch’lere bölünmeli ve asenkron işlenmeli
  • Kanal izolasyonu: Uygulama içi feed, push ve e-posta bağımsız çalıştırılmalı; bir kanaldaki arıza diğer kanallara yayılmamalı
  • Önceliklendirme: Zamana duyarlı bildirimler, özel queue’lar ve worker pool’ları kullanılarak normal bildirimlerden ayrılmalı
  • Gözlemlenebilirlik: Filtreleme ve teslim sonuçları incelenebilmeli, bildirim yaşam döngüsünün tamamındaki gecikme ölçülebilmeli
  • Genişletilebilirlik: Alıcı listesi oluşturma gibi gelecekteki özellikler başka bir büyük ölçekli refactor olmadan eklenebilmeli

Notification Factory ile iş mantığının ayrılması

• Platform orkestrasyonu ile bildirim bazlı iş mantığını ayırmak için Notification Factory soyutlaması getirildi
• Her factory, bildirim işlemenin planı olarak şu öğeleri tanımlar
  • İşleme önceliği
  • Uygulanacak bildirim ayarları
  • Alıcı filtreleme yöntemi
  • Bildirim bazlı uygunluk kontrolleri
  • Kanal bazlı payload üretme yöntemi
• Bu desen, Patreon’un kendi dağıtık görev motorunu temel alır ve birçok kavramı paylaşır
• Notification modeli, belirli bir bildirime özgü olup tüm alıcıların paylaştığı verileri içeren iş argümanlarını tanımlar
• Bağlı BaseNotificationFactory alt sınıfı, görev işleyicisi gibi davranır; alıcıları filtreleyen ve bildirimleri üreten ayar ve metotları içerir
• Yalnızca serialize edilmiş bildirim payload’unu alan fanout işlerinin çalıştıracağı iş mantığını bulabilmesi için, her Notification modelini ilgili factory sınıfına eşleyen bir registry kullanılır
• Çeşitli bildirim türlerini desteklerken yaygın implementasyon hatalarını ve verimsiz veri sorgularını da önlemek gerekiyordu
  • Patreon’da birden fazla kullanıcı kaydı türü ve filtreleme yöntemi bulunduğundan alıcı arayüzü genelleştirildi
  • Kullanıcı ayarları ve bildirim bazlı uygunluk kontrolleri uygulanabilsin diye net hook’lar sağlandı

Tek API ve 2 aşamalı fanout

• Geçmişte her kanal için ayrı gönderim API’si kullanıldığı için uygulama içi feed, push ve e-posta akışları birbirinden farklılaşabiliyor; ürün ekipleri de kanal bazlı davranışları çok erken aşamada düşünmek zorunda kalıyordu
• Yeniden tasarım sonrası giriş noktası tek API olan send_fanout_notifications altında birleştirildi
  • Çağıran taraf, bildirim payload’unu, alıcı listesini ve teslim gecikmesini ölçmekte kullanılacak timestamp’i geçirir
  • API, ilgili bildirimin factory’sini bulur, batch boyutunu ve önceliği belirler, ardından kanal bazlı işleri bağımsız olarak dağıtır
  • Bir kanaldaki hata veya gecikme diğer kanalları durdurmaz
• İlk aşama bildirim üretimini ölçeklemekten sorumludur
  • Tüm alıcı listesini küçük batch’lere böler
  • Her batch FanoutNotifications işi tarafından işlenir
  • İş, alıcıları filtreler, bildirim bazlı uygunluk kontrollerini çalıştırır ve Notification Factory ile kanal bazlı payload’ları üretir
• İkinci aşama teslim devrini ölçeklemeyi üstlenir
  • Üretilen bildirimleri uygulama içi feed, push ve e-posta için özel teslim işlerine yeniden fanout eder
• Temel bileşen olan FanoutNotifications işleyicisi, API ile mevcut kanal teslim sistemleri arasında yer alır; tek bir dev işi, bağımsız işlenebilen çok sayıda küçük işe dönüştürür

Alıcı bazlı gözlemlenebilirlik ve hata ayıklama

• Bildirimler, kullanıcının ayarları devre dışı bırakması, uygunluk kontrolünü geçememesi veya e-posta adresine teslim edilememesi gibi birçok nedenle başarısız olabilir ya da atlanabilir
• Eski platformda belirli bir bildirimin işleme sonucunu kontrol etmek için birden fazla sistemdeki log ve verileri birleştirmek gerekiyordu; kapsamlı alıcı bazlı yürütme takibi de olmadığından inceleme saatler sürebiliyordu
• Yeni platform şu sorulara yanıt verecek şekilde tasarlandı
  • Bildirim gönderiminin ne kadar sürdüğü
  • İlk alıcı listesinin ne kadar büyük olduğu
  • Kaç kişinin hangi nedenle filtrelendiği
  • Kanal bazında kaç bildirimin başarıyla gönderildiği
  • Belirli bir kullanıcının belirli bir bildirimi neden aldığı veya almadığı
• Platform genelinde aktarılan bir zamanlama ve logging veri modeli tanıtıldı
  • Bildirim akışının her aşamasında timestamp kaydedilir
  • Hem toplu sonuçlar hem de alıcı bazlı sonuçlar için metrikler ve event’ler üretilir
  • Geliştiriciler, ilgili entity’leri yürütme izlerine ve event’lere dahil etmek için logging öznitelikleri ekleyebilir
• Gözlemlenebilirlik, uyarılar, dashboard’lar ve hata ayıklama araçları iyileştikçe ürün mühendisleri ve destek ekipleri, platform mühendislerine bağımlı olmadan daha fazla sorunu inceleyebilir hale geldi

200’den fazla bildirimin migration’ı

• Notification Factory deseni, bildirimlerin geliştirilme ve bakım şeklini baştan değiştirdiği için yalnızca basit bir kod dönüştürme aracı (codemod) ile taşınamazdı
• Her bildirimin iş mantığını, veri bağımlılıklarını, uygunluk kurallarını ve kanal bazlı davranışlarını olduğu gibi korumak gerekiyordu
• Migration dokümanları ve örnek el ile migration PR’ları temel alınarak bir yapay zeka skill’i oluşturuldu
  • Geliştiriciler /migrate-notif-fanout <notif_name> komutunu çalıştırarak ilk migration çıktısını oluşturabiliyordu
  • Bildirim modeli oluşturma, factory bağlama, çağrı noktalarını değiştirme ve platform desenlerini uygulama gibi tekrarlı işlerde etkiliydi
• Yapay zeka ince iş mantıklarını kaçırabildiği, halüsinasyon yapabildiği veya temizlenmesi gereken tekrar kod üretebildiği için mühendislik yargısının yerini almadı
• 200’den fazla bildirim migrate edildi; yapay zeka kullanımını da içeren büyük ölçekli iş birliğiyle kalan %80’lik bölüm 6 haftada tamamlandı

Performans iyileştirmeleri ve ürün geliştirmeye etkisi

• Alıcı başına bildirim üretimi yatay ölçeklenebilen işlere taşınarak, tek bir içerik üretici başına milyonlarca bildirimin timeout olmadan güvenilir şekilde üretilebilmesi sağlandı
• Büyük içerik üreticilerin yüksek hacimli bildirim performansı ciddi şekilde iyileşti
  • Push ve uygulama içi feed bildirimleri %80 hızlandı
  • E-posta bildirimleri %55 hızlandı
  • Kitle 4 kat büyüdüğünde push ve uygulama içi feed için uçtan uca gecikme %33, e-posta için %60 arttı
  • Aynı koşullarda eski platformdaki gecikme artışı %186 idi
• Ürün ekiplerinin artık her yüksek hacimli bildirim için ayrı bir ölçekleme çözümü tasarlaması gerekmedi; geliştirme hızı da arttı
• Yeni platform, 2025’teki Lives, Quips ve büyük içerik üreticileri kazanma gibi önemli lansmanları destekledi
• Fanout yeniden tasarımı olmasaydı bu lansmanlar mevcut darboğazlara takılacak ve tek seferlik ölçekleme çözümleri geliştirmek için ek mühendislik zamanı gerekecekti
• Aşama bazlı zamanlama metrikleriyle zamanın nerede harcandığı belirlenebilir, altyapı hız ve maliyet dengesi doğrultusunda ayarlanabilir hale geldi

9 ay paralel işletim ve organizasyonel koordinasyon

• Çalışır durumdaki legacy sistemi değiştirirken birden fazla ekibin migration’ını koordine etmek işin en zor kısmıydı
• 9 ay boyunca iki bildirim sistemi paralel işletildi
  • Tüm platform değişikliklerinin hem eski yol hem de yeni fanout yolu ile uyumlu olması gerekiyordu
  • Bug ve arızaların ortaya çıkabileceği alan genişledi; migration uzadıkça operasyonel risk de arttı
  • Uyumluluk sorunları birkaç küçük arızaya yol açtı ve migration’ı hızlı ve güvenli biçimde bitirme ihtiyacını artırdı
• Başlangıçta her ürün ekibinin kendi bildirim migration önceliklerini belirlediği tabandan yukarı bir yaklaşım seçildi
  • 6 ayda yalnızca yaklaşık %20 taşınabildi
  • Ürün roadmap’i ve diğer ekip öncelikleri arasında geri plana düştüğü için ilerleme yavaşladı
• Mühendislik liderliği 2026’nın 1. çeyreğinde tamamlanması konusunda mutabık kalıp net bir son tarih ve şirket genelinde öncelik verdikten sonra, kalan migration’lar 6 haftada tamamlandı
• Tüm çalışmaya 10 ekip ve 30’dan fazla mühendis katıldı
  • Notion takipçisi ve otomasyonla ilerleme yönetildi
  • Paydaşlarla sık iletişim kuruldu ve işler birden fazla ekibe dağıtıldı
  • Platform ekibi migration’ların yaklaşık yarısını yaptıktan sonra dağıtım ve temizliği bildirim sahibi ekiplere devretti
  • Çok bildirimi olan ekiplerde iş yükünün yoğunlaşmaması için yük dağıtıldı
• İlerlemeyi hızlandırmak ve tamamlanmayı kutlamak için office hour’lar, leaderboard, ödüller ve happy hour içeren bir bildirim migration haftası düzenlendi
• Genel son tarihten 2 hafta önce devirleri bitirecek bir tampon süre ayrıldı
  • Ek desteğe ihtiyaç duyan ekiplere yardım edildi ve codebase’de eksik işler arandı
  • Son kontrolde yeni gerekli 4 migration ve birkaç tamamlanmamış kalem bulundu; takvime yalnızca küçük bir etkiyle işler kapatıldı

Büyük ölçekli platform migration’ından çıkarılan dersler

• Açık öncelik olmadığında, birden fazla ekibe yayılan migration’lar ekiplerin roadmap’leriyle rekabet eder ve kolayca geri plana atılır
  • Bu durum, ölçek etkisi daha az görünür olan düşük hacimli bildirimlerin uzun kuyruk bölümünde özellikle belirgindi
  • Liderlik mutabakatı, ortak öncelik ve net son tarih, migration’ı makul bir sürede bitirmek için kritik oldu

• Platform işi API’de bitmez

  • Önceden, diğer ekiplerin bildirim sorularını ve teslim sorunlarını araştırmak platform mühendislerinin on-call işinin önemli bir bölümünü oluşturuyordu
  • Gözlemlenebilirlik, uyarılar, dashboard’lar ve hata ayıklama araçları birlikte iyileştirilmelidir ki ürün ve destek ekipleri bağımsız inceleme yapabilsin, platform on-call yükü de azalsın
  • Yalnızca mevcut darboğaz değil, bir sonraki darboğaz da dikkate alınmalıdır
  • Tek bir projeyle tüm bildirim ölçekleme sorunlarını çözmek mümkün değildi
  • Gelecekteki özellikleri barındıracak şekilde tasarlamak, bildirim hacmi arttığında başka bir büyük refactor gerektirme olasılığını azalttı

Bir sonraki darboğaz ve gelecek planları

• Bildirim üretimi ölçeklendi; ancak bir sonraki darboğaz alıcı listesi oluşturma
• Bildirim hedef kitlesi büyümeye devam ettikçe milyonlarca alıcıyı verimli şekilde sorgulamak giderek daha önemli hale geliyor
• Alıcı listesi oluşturmayı Notification Factory’ye dahil ederek platformun uçtan uca bildirim akışının daha fazlasını üstlenmesi planlanıyor
• Bildirim ayarları da hem geliştiriciler hem de hayranlar tarafında iyileştirilecek
  • Geliştiricilerin yeni ayarları daha kolay oluşturup yönetmesi desteklenecek
  • Hayranların bildirim tercihlerini daha kolay anlaması ve kontrol etmesi sağlanacak