Membangun Sistem Notifikasi Tangguh: Microservice FastAPI, Kafka, dan FCM

Subscribe dengan Account Google untuk mendapatkan News Letter terbaru dari Halovina !
Membangun Sistem Notifikasi Tangguh: Microservice FastAPI, Kafka, dan FCM

Di era digital, notifikasi real-time adalah tulang punggung interaksi pengguna. Namun, mengirimkan jutaan notifikasi tanpa mengganggu kinerja sistem utama membutuhkan arsitektur yang kuat dan tangguh.

Artikel ini akan membedah blueprint sistem notifikasi event-driven yang memadukan FastAPI, Apache Kafka, dan Firebase Cloud Messaging (FCM).

A) Inti Arsitektur: Pemisahan Tanggung Jawab


Desain yang diusulkan mengadopsi pola Microservice dengan pemisahan tanggung jawab yang jelas melalui Event-Driven Architecture (EDA).

Konsep utamanya adalah memisahkan layanan yang menerima permintaan dari klien (Publisher) dengan layanan yang menangani pemrosesan dan pengiriman yang berat (Consumer).

Pemisahan ini membuat Publisher selalu tersedia dan tidak perlu menunggu respons dari layanan pengiriman eksternal (FCM), menciptakan sistem yang sangat responsive dan fault-tolerant.

B) Alur Data End-to-End: Dari Klien hingga Perangkat


Berikut adalah langkah-langkah detail bagaimana sebuah notifikasi berjalan dalam sistem ini:



  1. Request Klien (API Call)



    • Layanan backend lain (Klien HTTP) mengirimkan permintaan POST ke Publisher Service. Permintaan ini umumnya berisi user_id target dan detail pesan notifikasi.






  2. Publikasi Pesan (FastAPI Producer)



    • Publisher Service yang dibangun dengan FastAPI menerima permintaan. Setelah memvalidasi data, ia memperkaya pesan (misalnya menambahkan timestamp atau metadata lainnya).




    • Pesan ini kemudian dipublikasikan ke topic Kafka bernama "notifications".






  3. Penyimpanan Aman (Kafka Broker)



    • Kafka Broker menerima pesan dan menyimpannya secara persisten dalam topic tersebut. Ini adalah jaring pengaman yang memastikan tidak ada data yang hilang (guaranteed delivery) meskipun Consumer Service sedang down atau sibuk.






  4. Konsumsi Pesan (FastAPI Consumer Group)



    • Consumer Service, yang juga menggunakan FastAPI (seringkali dengan background tasks atau library consumer asinkron), terus-menerus mengambil (poll) pesan dari topic "notifications".




    • Dengan menggunakan Consumer Group, kita dapat dengan mudah melakukan skala horizontal pada Consumer Service untuk memproses volume notifikasi yang besar secara paralel.






  5. Pengambilan Token (Token Mapping Store Lookup)



    • Setelah menerima pesan yang berisi user_id, Consumer Service melakukan kueri ke Penyimpanan Pemetaan Token (misalnya Redis, Cassandra, atau database yang dioptimalkan) untuk mendapatkan Token Perangkat FCM yang terkait dengan user_id tersebut.






  6. Pengiriman ke FCM (Firebase Admin SDK)



    • Consumer Service menggunakan Firebase Admin SDK untuk mengirimkan permintaan push notification ke backend FCM, menggunakan token perangkat yang telah didapatkan.






  7. Pengiriman ke Perangkat (FCM Delivery)



    • FCM, sebagai layanan notifikasi Google, menangani sisanya, yaitu mengirimkan notifikasi secara real-time ke perangkat Android target.






C) Mengapa Memilih Kombinasi Ini?


 


  • FastAPI: Dipilih karena performa tinggi (setara dengan Node.js/Go) dan kemudahan pengembangan API asinkron dengan Python, sangat cocok untuk Publisher Service yang membutuhkan latensi rendah.




  • Kafka: Menyediakan decoupling (pemisahan) yang kuat dan back-pressure handling yang efisien. Publisher tidak perlu peduli seberapa cepat Consumer memproses pesan. Kafka dapat menahan lonjakan data.




  • FCM: Solusi terkemuka untuk pengiriman notifikasi seluler, menawarkan keandalan dan integrasi mendalam dengan ekosistem Android.