Event-Driven Architecture

Bayangkan kamu sedang membangun sistem pemesanan tiket konser. Tiket mulai dijual, ribuan orang masuk ke aplikasi secara bersamaan. Microservice pemesanan mulai kewalahan, request menumpuk, beberapa pengguna dapat tiket yang sama karena dua service membaca stok di waktu yang hampir bersamaan. Tim panik, server restart, dan sebagian pengguna kehilangan antrean mereka.

Skenario seperti ini bukan cerita langka. Banyak tim yang membangun sistem dengan komunikasi sinkron—service A memanggil service B, menunggu jawaban, lalu melanjutkan. Pola ini sederhana dan mudah dipahami, tetapi ketika beban melonjak atau salah satu service lambat, efeknya merambat ke semua service yang bergantung padanya. Service yang tadinya cepat tiba-tiba ikut lambat karena menunggu jawaban dari service lain.

Masalah Kopling Sinkron

Dalam arsitektur monolitik atau service yang saling memanggil secara langsung, setiap permintaan menciptakan rantai ketergantungan. Service pemesanan harus menunggu service pembayaran, service pembayaran menunggu service notifikasi, dan seterusnya. Jika satu mata rantai putus, seluruh permintaan gagal.

Masalahnya bukan hanya soal performa. Kopling sinkron membuat tim sulit mengubah atau mengganti service tanpa mempengaruhi service lain. Service baru yang ingin memanfaatkan data dari service lama harus menunggu service lama selesai diproses. Perubahan kecil di satu service bisa menyebabkan efek domino yang sulit dilacak.

Di sinilah pola event-driven architecture mulai terasa relevan. Alih-alih service saling memanggil secara langsung, mereka berkomunikasi melalui peristiwa—event—yang dikirim ke broker pusat. Service pengirim tidak peduli siapa yang menerima event tersebut. Service penerima tidak peduli siapa yang mengirimnya. Mereka hanya perlu sepakat tentang format event dan topik yang digunakan.

Komponen Utama dalam Event-Driven Architecture

Event-driven architecture terdiri dari tiga blok utama yang bekerja bersama: event producers, event broker, dan event consumers.

Event Producers adalah service atau sistem yang menghasilkan event. Dalam contoh tiket konser tadi, microservice pemesanan adalah producer. Setiap kali pengguna berhasil memesan tiket, service ini mengirim event “ticket.booked” ke broker. Producer tidak perlu tahu apakah ada service lain yang mendengarkan event tersebut. Ia hanya perlu mengirim event dengan format yang sudah disepakati.

Event Broker adalah pusat dari arsitektur ini. Broker menerima event dari producer, menyimpannya, dan meneruskannya ke consumer yang sudah berlangganan topik tertentu. Broker terdiri dari beberapa komponen internal: topic atau channel router yang menentukan ke mana event harus dikirim, message queue yang menampung event sementara, dan event store yang menyimpan event untuk keperluan replay atau audit. Broker memastikan event tidak hilang meskipun consumer sedang sibuk atau mati.

Event Consumers adalah service yang mendaftar untuk menerima event dari topik tertentu. Dalam contoh konser, consumer bisa berupa microservice yang memperbarui stok tiket, analytics service yang mencatat pola pembelian, atau notification service yang mengirim email konfirmasi. Consumer memproses event secara asynchronous—mereka mengambil event dari broker, memprosesnya, dan bisa juga menghasilkan event baru sebagai respons.

Bagaimana Alur Kerjanya

Alur kerja event-driven architecture mengikuti tiga langkah utama yang sederhana.

Pertama, producer mengirim event ke broker pada topik tertentu. Event ini berisi data tentang apa yang terjadi—misalnya, “pengguna dengan ID 1234 berhasil memesan tiket kategori VIP.” Producer tidak menunggu respons. Ia langsung melanjutkan tugasnya setelah event terkirim.

Kedua, broker menerima event dan menentukan consumer mana yang berlangganan topik tersebut. Broker menyimpan event di queue dan mulai mengirimkannya ke consumer yang siap memproses. Jika consumer sedang sibuk, event tetap aman di queue sampai consumer siap.

Ketiga, consumer mengambil event dari broker dan memprosesnya. Consumer bisa melakukan berbagai hal: memperbarui database, mengirim notifikasi, memicu proses bisnis lain, atau bahkan mengirim event baru ke topik lain. Misalnya, setelah notification service mengirim email konfirmasi, ia bisa mengirim event “notification.sent” yang akan diproses oleh service lain.

Kapan Pola Ini Cocok Dipakai

Event-driven architecture sangat cocok untuk sistem yang membutuhkan skalabilitas tinggi dan respons real-time. Jika sistemmu harus menangani lonjakan traffic yang tidak terduga, pola ini memungkinkanmu menambah consumer secara horizontal tanpa mengubah producer.

Pola ini juga ideal untuk microservices orchestration. Ketika satu aksi bisnis melibatkan banyak service—seperti pemesanan tiket yang melibatkan pembayaran, notifikasi, dan update stok—event-driven architecture memungkinkan setiap service bekerja secara independen tanpa menunggu service lain.

Penggunaan lain yang umum adalah real-time analytics. Service analytics bisa berlangganan semua event yang terjadi di sistem dan memprosesnya untuk menghasilkan insight tanpa mengganggu service utama. IoT event processing juga sangat cocok, di mana perangkat mengirim event secara terus-menerus dan sistem perlu memprosesnya tanpa kehilangan data.

Trade-off, Batasan, dan Risiko Operasional

Event-driven architecture bukan solusi untuk semua masalah. Pola ini membawa trade-off yang perlu dipahami tim sebelum mengadopsinya.

Konsistensi data menjadi eventual, bukan immediate. Ketika producer mengirim event, consumer mungkin memprosesnya beberapa detik atau menit kemudian. Jika sistemmu membutuhkan konfirmasi langsung bahwa data sudah diproses—misalnya, pengguna harus langsung melihat stok tiket yang diperbarui setelah pembayaran—pola sinkron mungkin lebih cocok.

Debugging dan tracing menjadi lebih sulit. Karena event mengalir melalui broker dan diproses secara asynchronous, melacak alur lengkap dari satu aksi bisnis membutuhkan alat tracing yang baik. Tim harus siap dengan observability yang matang.

Message ordering bisa menjadi tantangan. Jika dua event terjadi dalam waktu berdekatan, broker mungkin mengirimkannya ke consumer yang berbeda, menyebabkan urutan pemrosesan berbeda dari urutan kejadian. Untuk kasus di mana urutan penting—seperti update saldo rekening—tim perlu menggunakan partition key atau mekanisme ordering lain.

Duplicate events adalah kenyataan yang harus dihadapi. Consumer harus dirancang secara idempotent—artinya, memproses event yang sama dua kali tidak boleh menyebabkan efek ganda. Ini membutuhkan logika tambahan di sisi consumer.

Implikasi Praktis untuk Tim Engineering

Mengadopsi event-driven architecture bukan hanya keputusan teknis, tetapi juga keputusan operasional dan organisasi.

Tim perlu berinvestasi dalam schema registry untuk mengelola versi event. Ketika producer mengubah format event, consumer lama harus tetap bisa memproses event versi lama. Tanpa schema registry, perubahan kecil bisa menyebabkan consumer gagal memproses event.

Monitoring menjadi kritis. Tim harus memantau lag consumer—berapa lama event menunggu di queue sebelum diproses. Lag yang tinggi menandakan consumer kewalahan atau ada masalah. Tim juga perlu memantau throughput broker dan memastikan kapasitasnya mencukupi.

Keamanan event perlu diperhatikan. Event dalam perjalanan dan saat disimpan harus dienkripsi. Akses ke topik harus dibatasi—hanya producer dan consumer yang berwenang yang bisa mengirim atau membaca event dari topik tertentu. Audit log event membantu melacak siapa yang mengakses event apa.

Tim juga perlu mempertimbangkan strategi error handling. Jika consumer gagal memproses event, apakah event akan di-retry, dikirim ke dead letter queue, atau diabaikan? Setiap keputusan memiliki konsekuensi operasional yang perlu dipahami.

Event-driven architecture memberikan fleksibilitas dan skalabilitas yang sulit dicapai dengan pola sinkron. Namun, fleksibilitas ini datang dengan biaya kompleksitas yang nyata. Tim yang mengadopsi pola ini harus siap dengan investasi di tooling, monitoring, dan disiplin operasional yang lebih tinggi. Jika tim sudah siap, pola ini bisa menjadi fondasi yang kokoh untuk sistem yang tumbuh dan berubah seiring waktu.