Arsitektur Event-Driven: Bereaksi, Bukan Bertanya

Dalam arsitektur event-driven, layanan tidak memanggil satu sama lain secara langsung. Sebaliknya, sebuah layanan mengumumkan “ini terjadi” dan layanan lain yang tertarik bereaksi.

Keuntungan: kopling longgar

Pengirim tidak perlu tahu siapa penerima. Menambah konsumen baru tidak mengubah pengirim. Ini memudahkan evolusi dan menurunkan kopling antar tim.

Tantangan: alur tak terlihat

Kopling longgar punya sisi gelap: alur bisnis tersebar di banyak layanan. Tanpa dokumentasi dan tracing, sulit melihat “apa yang terjadi saat pesanan dibuat”. Disiplin observabilitas wajib.

Kapan berlebihan

Tidak setiap interaksi perlu event. Untuk query sederhana yang butuh jawaban langsung, panggilan sinkron lebih jujur. Event-driven bukan dogma, melainkan pilihan untuk ketahanan dan skalabilitas.