Bagaimana Patreon Menskalakan Sistem Notifikasinya dengan Fanout

• Sistem berusia 13 tahun yang telah menangani puluhan miliar notifikasi per tahun mulai mengalami timeout saat satu kreator besar dapat menghasilkan jutaan notifikasi, sehingga Patreon mendesain ulangnya dengan lapisan fanout yang membuat notifikasi per penerima lebih dulu
• Dengan menerapkan fanout dua tahap yang membagi daftar penerima menjadi batch kecil dan memproses feed in-app, push, dan email secara independen, Patreon memperoleh skalabilitas horizontal dan isolasi kegagalan antar kanal
• Untuk kreator besar, feed push dan in-app menjadi 80% lebih cepat, email 55% lebih cepat, dan saat audiens tumbuh 4 kali lipat, kenaikan latensi end-to-end turun dari 186% menjadi masing-masing 33% dan 60%
• Dengan Notification Factory dan satu API send_fanout_notifications, Patreon menstandarkan pemfilteran, pemeriksaan kelayakan, dan pembuatan payload, sekaligus melacak timing per tahap dan hasil per penerima untuk menyederhanakan operasi dan debugging
• 10 tim dan lebih dari 30 engineer memigrasikan lebih dari 200 notifikasi, dan pembuatan draf berbasis AI bersama tenggat yang jelas dari kepemimpinan membantu mengurangi pekerjaan berulang dan operasi paralel jangka panjang

---

Batas skalabilitas yang terungkap oleh kreator besar

• Patreon mengirim puluhan miliar notifikasi per tahun kepada penggemar saat kreator menerbitkan postingan atau memulai livestream
• Seiring peluncuran membership gratis dan pertumbuhan platform, jumlah penggemar per kreator melonjak, dan pada awal 2025 bottleneck performa yang serius mulai terlihat, terutama pada kreator besar
• Notifikasi postingan lama memiliki struktur di mana satu pekerjaan asinkron mengambil seluruh penerima, memfilter berdasarkan pengaturan tiap pengguna, membuat payload untuk setiap penerima, lalu menyerahkannya ke sistem pengiriman feed in-app, push, dan email
• Untuk kreator besar, satu pekerjaan tunggal ini harus menangani pembuatan jutaan notifikasi, sehingga timeout terus terjadi dan pengiriman notifikasi secara andal ke audiens besar menjadi sulit
• Ada dua batasan struktural pada alur lama
  • Biaya pembuatan per penerima terkonsentrasi pada satu pekerjaan asinkron sehingga skalabilitas horizontal tidak mungkin dilakukan dan throughput memiliki batas atas yang jelas
  • Feed in-app, push, dan email saling terikat erat sehingga kegagalan pada satu kanal dapat memblokir kanal lain juga
• Beberapa tim produk sempat membuat pendekatan penskalaan terpisah untuk notifikasi volume tinggi mereka masing-masing, yang menyelesaikan masalah jangka pendek tetapi meningkatkan kompleksitas platform dan mempersulit pengembangan, operasi, serta debugging
• Patreon memutuskan untuk mempertahankan sistem pengiriman yang ada, tetapi menempatkan lapisan fanout bersama di depannya untuk menyediakan skalabilitas horizontal, isolasi kanal, dan observabilitas

Enam syarat desain untuk platform fanout

• Lapisan baru dirancang untuk membagi daftar penerima besar menjadi batch kecil, membuat notifikasi per penerima, lalu mengirimkannya ke sistem feed in-app, push, dan email yang sudah ada
• Enam persyaratan berikut diterapkan pada platform
  • Ramah developer: setiap notifikasi volume tinggi tidak boleh harus menyelesaikan skalabilitas dan keandalan dari nol, sambil tetap mendukung beragam kasus dan mengurangi kesalahan penggunaan
  • Skalabilitas horizontal: daftar penerima harus otomatis dibagi menjadi batch kecil untuk diproses secara asinkron
  • Isolasi kanal: feed in-app, push, dan email harus berjalan independen sehingga gangguan pada satu kanal tidak menyebar ke kanal lain
  • Pemrosesan prioritas: notifikasi yang sensitif terhadap waktu harus dipisahkan dari notifikasi umum dengan queue dan worker pool khusus
  • Observabilitas: harus bisa menyelidiki hasil pemfilteran dan pengiriman, serta mengukur latensi di seluruh siklus hidup notifikasi
  • Ekstensibilitas: fitur masa depan seperti pembuatan daftar penerima harus bisa ditambahkan tanpa refactor besar lainnya

Memisahkan logika bisnis dengan Notification Factory

• Untuk memisahkan orkestrasi platform dari logika bisnis spesifik notifikasi, Patreon memperkenalkan abstraksi Notification Factory
• Setiap factory mendefinisikan blueprint pemrosesan notifikasi melalui elemen berikut
  • prioritas pemrosesan
  • pengaturan notifikasi yang diterapkan
  • cara memfilter penerima
  • pemeriksaan kelayakan khusus notifikasi
  • cara membuat payload per kanal
• Pola ini dibangun di atas mesin pekerjaan terdistribusi internal milik Patreon dan berbagi beberapa konsep dengannya
• Model Notification mendefinisikan argumen pekerjaan yang menyimpan data unik untuk notifikasi tertentu tetapi dibagikan oleh semua penerima
• Subclass BaseNotificationFactory yang terhubung bertindak sebagai handler pekerjaan dan berisi konfigurasi serta metode untuk memfilter penerima dan membuat notifikasi
• Agar pekerjaan fanout yang hanya menerima payload notifikasi yang telah diserialisasi bisa menemukan logika bisnis yang harus dijalankan, Patreon menggunakan registry yang memetakan setiap model Notification ke kelas factory terkait
• Platform harus mendukung beragam jenis notifikasi sekaligus mencegah kesalahan implementasi umum dan query data yang tidak efisien
  • Karena Patreon memiliki beberapa jenis record pengguna dan metode pemfilteran, antarmuka penerima digeneralisasi
  • Hook yang jelas disediakan untuk mengimplementasikan pengaturan pengguna dan pemeriksaan kelayakan khusus notifikasi

Satu API dan fanout dua tahap

• Dulu, setiap kanal memiliki API pengiriman terpisah sehingga alur feed in-app, push, dan email bisa berbeda, dan tim produk juga harus memikirkan perilaku per kanal terlalu dini
• Setelah didesain ulang, titik masuk disatukan ke satu API, yaitu send_fanout_notifications
  • Pemanggil mengirim payload notifikasi, daftar penerima, dan timestamp yang akan digunakan untuk mengukur latensi pengiriman
  • API mencari factory untuk notifikasi tersebut, menentukan ukuran batch dan prioritas, lalu mendistribusikan pekerjaan per kanal secara independen
  • Kegagalan atau keterlambatan pada satu kanal tidak memblokir kanal lain
• Tahap pertama bertanggung jawab atas penskalaan pembuatan notifikasi
  • Daftar penerima penuh dibagi menjadi batch kecil
  • Setiap batch diproses oleh pekerjaan FanoutNotifications
  • Pekerjaan ini memfilter penerima, menjalankan pemeriksaan kelayakan spesifik notifikasi, lalu menggunakan Notification Factory untuk membuat payload per kanal
• Tahap kedua menangani penskalaan serah-terima pengiriman
  • Notifikasi yang telah dibuat di-fanout lagi ke pekerjaan pengiriman khusus feed in-app, push, dan email
• Handler pekerjaan inti FanoutNotifications berada di antara API dan sistem pengiriman kanal lama, mengubah satu pekerjaan raksasa menjadi banyak pekerjaan kecil yang bisa diproses secara independen

Observabilitas dan debugging per penerima

• Notifikasi bisa gagal atau dilewati karena berbagai alasan, misalnya pengguna menonaktifkan pengaturan, tidak lolos pemeriksaan kelayakan, atau email tidak dapat dikirim ke alamat yang tersedia
• Di platform lama, untuk memeriksa hasil pemrosesan notifikasi tertentu, orang harus menggabungkan log dan data dari beberapa sistem, dan karena tidak ada pelacakan eksekusi per penerima yang komprehensif, investigasi bisa memakan waktu berjam-jam
• Platform baru dirancang agar dapat menjawab pertanyaan berikut
  • berapa lama pengiriman notifikasi berlangsung
  • seberapa besar daftar penerima awal
  • berapa banyak orang yang difilter dan karena alasan apa
  • berapa banyak yang berhasil dikirim per kanal
  • mengapa pengguna tertentu menerima atau tidak menerima notifikasi tertentu
• Patreon memperkenalkan model data timing dan logging yang mengalir di seluruh platform
  • timestamp dicatat pada setiap tahap alur notifikasi
  • metrik dan event dibuat baik untuk hasil agregat maupun hasil per penerima
  • developer dapat menambahkan properti logging agar entitas terkait ikut dimasukkan ke jejak eksekusi dan event
• Dengan observabilitas, alerting, dashboard, dan alat debugging yang lebih baik, engineer produk dan tim dukungan dapat menyelidiki lebih banyak masalah tanpa bergantung pada engineer platform

Migrasi lebih dari 200 notifikasi

• Karena pola Notification Factory mengubah cara notifikasi dikembangkan dan dipelihara itu sendiri, migrasi tidak bisa dilakukan hanya dengan alat transformasi kode (codemod) sederhana
• Logika bisnis, dependensi data, aturan kelayakan, dan perilaku per kanal untuk tiap notifikasi harus dipertahankan apa adanya
• Berdasarkan dokumentasi migrasi dan PR migrasi manual yang menjadi contoh, Patreon membangun skill AI
  • Developer dapat menjalankan /migrate-notif-fanout <notif_name> untuk menghasilkan hasil migrasi tahap pertama
  • Ini efektif untuk pekerjaan berulang seperti membuat model notifikasi, menghubungkan factory, memperbarui titik pemanggilan, dan menerapkan pola platform
• AI tidak menggantikan penilaian engineer, karena bisa melewatkan logika bisnis yang halus, berhalusinasi, atau menghasilkan kode duplikat yang masih perlu dirapikan
• Lebih dari 200 notifikasi berhasil dimigrasikan, dan lewat kolaborasi skala besar termasuk pemanfaatan AI, 80% sisanya selesai hanya dalam 6 minggu

Peningkatan performa dan dampak pada pengembangan produk

• Dengan memindahkan pembuatan notifikasi per penerima ke pekerjaan yang bisa diskalakan secara horizontal, Patreon kini dapat menghasilkan jutaan notifikasi per kreator secara stabil tanpa timeout
• Performa notifikasi volume tinggi untuk kreator besar meningkat tajam
  • notifikasi push dan feed in-app menjadi 80% lebih cepat
  • notifikasi email menjadi 55% lebih cepat
  • saat audiens tumbuh 4 kali lipat, latensi end-to-end push dan feed in-app meningkat 33%, sedangkan email meningkat 60%
  • pada kondisi yang sama, laju peningkatan latensi platform lama adalah 186%
• Tim produk tidak lagi perlu merancang solusi penskalaan terpisah untuk setiap notifikasi volume tinggi, dan kecepatan pengembangan pun meningkat
• Platform baru mendukung peluncuran penting pada 2025 seperti Lives, Quips, dan akuisisi kreator besar
• Tanpa redesain fanout ini, peluncuran-peluncuran tersebut akan menabrak bottleneck lama dan memerlukan waktu engineering tambahan untuk membuat solusi penskalaan sekali pakai
• Dengan metrik timing per tahap, Patreon kini bisa melihat di mana waktu dihabiskan dan menyesuaikan infrastruktur sesuai keseimbangan antara kecepatan dan biaya

Operasi paralel 9 bulan dan koordinasi organisasi

• Bagian tersulit adalah mengubah sistem legacy yang masih berjalan sambil mengoordinasikan migrasi lintas banyak tim
• Dua sistem notifikasi dijalankan paralel selama 9 bulan
  • Semua perubahan platform harus kompatibel baik dengan jalur lama maupun jalur fanout baru
  • Ruang lingkup bug dan gangguan menjadi lebih besar, dan semakin lama migrasi berlangsung, semakin tinggi pula risiko operasionalnya
  • Beberapa gangguan kecil sempat terjadi karena masalah kompatibilitas, sehingga kebutuhan untuk menyelesaikan migrasi dengan cepat dan aman menjadi makin jelas
• Awalnya Patreon memilih pendekatan bottom-up, di mana setiap tim produk menetapkan prioritas migrasi notifikasinya sendiri
  • Dalam 6 bulan, hanya sekitar 20% yang berhasil dimigrasikan
  • Laju progres melambat karena kalah prioritas dari roadmap produk dan prioritas tim lain
• Setelah pimpinan engineering menyepakati target selesai pada kuartal 1 2026 dan memberi tenggat yang jelas serta prioritas tingkat perusahaan, sisa migrasi selesai dalam 6 minggu
• Total pekerjaan melibatkan 10 tim dan lebih dari 30 engineer
  • Kemajuan dikelola dengan tracker Notion dan otomatisasi
  • Komunikasi dengan stakeholder dilakukan secara rutin, dan pekerjaan didistribusikan ke banyak tim
  • Tim platform menangani sekitar setengah dari migrasi sebelum menyerahkan deployment dan perapian kepada tim pemilik notifikasi
  • Beban kerja disebarkan agar tidak menumpuk pada tim yang memiliki banyak notifikasi
• Patreon mengadakan minggu migrasi notifikasi yang mencakup office hour, leaderboard, hadiah, dan happy hour untuk mempercepat progres sekaligus merayakan penyelesaiannya
• Buffer dua minggu diamankan sebelum tenggat keseluruhan untuk menyelesaikan serah terima
  • Waktu ini digunakan membantu tim yang masih memerlukan dukungan tambahan dan mencari pekerjaan yang terlewat di codebase
  • Pada pemeriksaan terakhir, ditemukan 4 migrasi baru yang diperlukan dan beberapa item yang belum selesai, tetapi semuanya dituntaskan dengan dampak jadwal yang kecil

Pelajaran dari migrasi platform skala besar

• Tanpa prioritas yang eksplisit, migrasi lintas banyak tim mudah terdorong ke belakang karena harus bersaing dengan roadmap masing-masing tim
  • Ini terutama terlihat pada long tail notifikasi ber-volume rendah, di mana manfaat skalanya kurang terasa
  • Kesepakatan pimpinan, prioritas bersama, dan tenggat yang jelas sangat penting untuk menyelesaikan migrasi dalam jangka waktu yang wajar

• Pekerjaan platform tidak berhenti di API

  • Sebelumnya, pertanyaan tentang notifikasi dari tim lain dan investigasi masalah pengiriman mengambil porsi besar dari tugas on-call engineer platform
  • Observabilitas, alerting, dashboard, dan alat debugging juga harus ditingkatkan agar tim produk dan dukungan bisa melakukan investigasi secara mandiri, sekaligus mengurangi beban on-call tim platform
  • Bukan hanya bottleneck saat ini, tetapi juga bottleneck berikutnya yang perlu dipikirkan
  • Satu proyek tidak mungkin menyelesaikan semua masalah skalabilitas notifikasi sekaligus
  • Dengan merancang agar bisa menampung fitur mendatang, kebutuhan akan refactor besar lainnya saat volume notifikasi tumbuh dapat dikurangi

Bottleneck berikutnya dan rencana ke depan

• Pembuatan notifikasi sudah diskalakan, tetapi bottleneck berikutnya adalah pembuatan daftar penerima
• Saat target notifikasi terus membesar, kemampuan mengambil jutaan penerima secara efisien akan menjadi semakin penting
• Patreon berencana memasukkan pembuatan daftar penerima ke dalam Notification Factory agar platform menangani lebih banyak bagian dari alur notifikasi end-to-end
• Pengaturan notifikasi juga akan ditingkatkan untuk developer maupun penggemar
  • developer akan didukung agar lebih mudah membuat dan mengelola pengaturan baru
  • penggemar akan dibantu agar lebih mudah memahami dan mengontrol preferensi notifikasi mereka