Fanout #

Dalam sistem event-driven, ada momen di mana satu event harus diketahui oleh banyak komponen sekaligus.

Misalnya:

• Order dibuat
• User terdaftar
• Pembayaran berhasil

Notification service perlu tahu. Analytics service perlu tahu. Audit service perlu tahu.

Di sinilah fanout exchange menjadi relevan.

Fanout exchange adalah mekanisme broadcast dalam RabbitMQ.

“Ketika sebuah peristiwa terjadi, terkadang bukan satu service yang perlu tahu — tetapi seluruh ekosistem harus bereaksi.”

Apa Itu Fanout Exchange? #

Fanout exchange adalah tipe exchange yang:

• Mengabaikan routing key
• Mengirim message ke semua queue yang ter-binding

Tidak ada matching. Tidak ada filtering.

Semua subscriber menerima message.

Cara Kerja Fanout Exchange #

1. Diagram Broadcast Fanout #

            Producer
                |
                v
          Fanout Exchange
            /      |      \
           v       v       v
        Queue A  Queue B  Queue C

Setiap queue yang ter-binding akan menerima salinan message.

Routing key tetap bisa dikirim oleh producer, tetapi tidak digunakan untuk matching.

Perbedaan Fanout dengan Direct dan Topic #

Fanout adalah tipe paling sederhana untuk distribusi ke banyak consumer.

Use Case Fanout Exchange #

Fanout cocok untuk:

Event Broadcast #

Contoh:

• user.registered
• order.completed

Semua service yang perlu bereaksi dapat membuat queue dan melakukan binding.

Logging dan Audit #

Satu event bisa diproses oleh:

• Service utama
• Logging service
• Monitoring service

Tanpa mengubah producer.

Cache Invalidation #

Ketika data berubah, semua cache node bisa menerima sinyal invalidasi.

Kelebihan Fanout Exchange #

Decoupling Maksimal #

Producer tidak tahu siapa saja subscriber.

Subscriber bisa ditambah atau dihapus tanpa mengubah producer.

Sederhana dan Predictable #

Tidak ada aturan matching kompleks.

Semua queue menerima message.

Cocok untuk Event-Driven Architecture #

Fanout sangat natural untuk event broadcast.

Keterbatasan Fanout Exchange #

Tidak Ada Filtering #

Jika hanya satu service yang membutuhkan event tertentu, fanout bisa berlebihan.

Semua queue akan menerima message.

Potensi Over-Delivery #

Jika banyak queue ter-binding, setiap event akan diduplikasi ke semua queue.

Ini bisa meningkatkan beban broker dan storage.

Kurang Cocok untuk Command Routing #

Command biasanya memiliki satu tujuan spesifik.

Fanout tidak cocok untuk pola command.

Fanout dan Scaling #

Setiap queue menerima salinan message.

Artinya:

• Storage meningkat per queue
• Throughput multiply berdasarkan jumlah subscriber

Desain harus mempertimbangkan ini jika event rate tinggi.

Fanout vs Topic untuk Event System #

Fanout cocok jika:

• Semua subscriber harus menerima semua event

Topic cocok jika:

• Subscriber hanya ingin subset tertentu

Dalam sistem besar, topic exchange sering lebih fleksibel.

Namun fanout tetap relevan untuk broadcast sederhana.

Kesalahan Umum #

Menggunakan Fanout untuk Semua Event #

Jika sistem berkembang, filtering menjadi sulit.

Tidak Mengontrol Jumlah Subscriber #

Semakin banyak queue ter-binding, semakin besar duplikasi message.

Tidak Memantau Storage #

Fanout meningkatkan total message footprint.

Best Practice #

Gunakan untuk Event Broadcast Global #

Contoh:

system.config.updated

Kombinasikan dengan Domain-Specific Exchange #

Jangan gunakan satu fanout untuk seluruh sistem tanpa segmentasi domain.

Monitor Queue Depth #

Pastikan setiap subscriber mampu memproses dengan stabil.

Ringkasan #

Penutup #

Fanout exchange adalah mekanisme broadcast paling sederhana dalam RabbitMQ.

Ia memungkinkan satu event didistribusikan ke banyak subscriber tanpa coupling.

Namun seperti semua alat yang sederhana dan kuat, ia harus digunakan dengan kesadaran penuh terhadap dampaknya.

Dalam arsitektur event-driven yang matang, fanout menjadi fondasi untuk pola publish-subscribe yang bersih dan terisolasi.

Karena kadang, satu peristiwa memang perlu didengar oleh semua pihak.