Arsitektur Event-Driven

Back to IF3130 Sistem Paralel dan Terdistribusi

Topic

Questions/Cues

• Apa beda model request-based vs event-based?

• Apa itu Broker Topology?

• Apa keuntungan arsitektur event-driven?

• Apa kerugian (trade-offs) nya?

• Apa itu Eventual Consistency?

• Apa dampak performa asinkronus?

Reference Points

• Slides 21-23 (10 - IF3130-09-Architecture-2022.pdf)

• Kuliah Arsitektur Sistem Terdistribusi

1. Request-Based vs Event-Based

Ini adalah dua model fundamental untuk interaksi antar komponen.

1. Request-Based Model (Sinkronus):

   

   • Ada Request Orchestrator (Pengatur) yang mengontrol alur.

   • Alur: UI mengirim Request → Orchestrator memanggil Processor A → Menunggu A selesai → Memanggil Processor B, dst.

   • Control flow sangat jelas dan eksplisit.

   • Komunikasi bersifat sinkronus (menunggu balasan).

2. Event-Based Model (Asinkronus):

   

   • Menggunakan topologi Broker.

   • Komponen Event Producer (misal: service A) mengirimkan event (pesan “sesuatu telah terjadi”) ke Event Channel / Broker (misal: Kafka, RabbitMQ).

   • Komponen Event Processor (misal: service B) subscribe (berlangganan) ke event tersebut. Ketika event muncul di Broker, Broker mengirimkannya ke Processor.

   • Producer tidak tahu (dan tidak peduli) siapa yang akan memproses event-nya.

   • Komunikasi bersifat asinkronus (fire-and-forget).

2. Trade-offs Event-Driven Architecture (EDA)

EDA memiliki keuntungan dan kerugian yang signifikan.

Keuntungan (Advantages):

• Responsif: Sistem bisa bereaksi secara real-time terhadap perubahan/kejadian.

• Skalabilitas & Elastisitas: Sangat mudah di-scale. Jika satu processor kewalahan, tinggal tambahkan instance processor baru yang subscribe ke event yang sama.

• Agility & Extensibility: Sangat mudah menambah fungsionalitas baru. Cukup buat service baru dan minta ia subscribe ke event yang ada, tanpa perlu mengubah service lama.

• Performance: Performa dirasakan (perceived performance) meningkat karena komunikasi asinkronus (dijelaskan di poin 3).

Kerugian (Trade-offs):

• Eventual Consistency: Karena asinkronus, data tidak akan konsisten secara instan. Ada jeda waktu. Contoh: Anda pesan tiket, status langsung “Pending”. Event diproses di background, dan beberapa detik kemudian status berubah jadi “Confirmed”. Sistem pada akhirnya (eventually) akan konsisten.

• Kontrol Alur Kurang: Sulit melacak alur proses secara keseluruhan. (Misal: “Setelah event A, apakah B atau C yang jalan duluan?”).

• Sulit di-Test dan di-Debug: Jauh lebih sulit melacak bug karena alurnya tidak linear dan tersebar di banyak processor.

3. Synchronous vs Asynchronous Communication

Asumsi: Proses di server (Consumer) butuh 3000ms.

• Synchronous (misal: REST):

  1. Producer kirim request (butuh 50ms).

  2. Producer WAIT (Menunggu).

  3. Consumer proses (3000ms).

  4. Consumer kirim response (50ms).

  5. Producer menerima response dan bebas (GO).

• Total Waktu Producer Terblokir: 3100ms.

• Asynchronous (misal: Event):

  1. Producer kirim event (butuh 25ms, lebih cepat karena protokol messaging ringan).

  2. Producer langsung bebas (GO). Broker akan mengurus pengiriman.

  3. Di background, Consumer menerima event (25ms) dan memprosesnya (3000ms).

• Total Waktu Producer Terblokir: 25ms.

Kesimpulan: Waktu proses total end-to-end mungkin sama (sekitar 3050ms), tapi responsiveness (dilihat dari sisi Producer) jauh lebih cepat di model asinkronus. Producer bisa langsung mengerjakan hal lain.

Summary

Arsitektur Berbasis Peristiwa (Event-Driven) mengubah model komunikasi dari request-reply sinkronus menjadi publish-subscribe asinkronus menggunakan event broker. Ini memberikan keuntungan besar dalam hal skalabilitas, fleksibilitas (extensibility), dan responsiveness (karena producer tidak terblokir lama). Namun, ini dibayar dengan kerugian berupa kompleksitas debugging dan model konsistensi data yang lebih lemah, yaitu Eventual Consistency.

Additional Information

Pendalaman: Eventual Consistency

Ini adalah konsep fundamental di sistem terdistribusi modern. Dalam sistem monolit, kita terbiasa dengan konsistensi ACID (Atomic, Consistent, Isolated, Durable), di mana setelah query UPDATE selesai, query SELECT berikutnya pasti melihat data baru.

Di Eventual Consistency, hal ini tidak dijamin. Setelah Anda mem-”publish” event, mungkin butuh beberapa milidetik (atau bahkan detik) sebelum processor menerima, memproses, dan menyimpan data baru. Jika Anda melakukan SELECT dalam jeda waktu itu, Anda akan melihat data lama.

Sistem ini “menerima” inkonsistensi sementara demi mendapatkan skalabilitas dan ketersediaan (availability) yang lebih tinggi (prinsip Teorema CAP).

Perbandingan

Aspek	Layered (N-Tier)	Service-Based	Event-Driven (EDA)
Definisi	Kode disusun secara horizontal berdasarkan peran teknis (misal: Presentation, Business, Database). Tiap layer hanya boleh bicara dengan layer di bawahnya.	Sistem dipecah menjadi beberapa layanan berdasarkan domain bisnis (misal: Order Service, User Service). Layanan ini berukuran besar (makro) dan seringkali masih berbagi satu database yang sama.	Arsitektur yang berpusat pada produksi dan konsumsi “event” (kejadian). Komponen tidak memanggil satu sama lain secara langsung, melainkan melempar pesan (event) secara asinkron.
Kelebihan (Pros)	• Simpel & Familiar: Paling mudah dipahami pemula. • Standar: Hampir semua framework (Spring, Django, Laravel) mendukung ini secara default. • Separation of Concern: Memisahkan UI dari logika bisnis dan database.	• Kompromi Terbaik: Lebih modular daripada Monolith Layered, tapi tidak serumit Microservices. • Deployment Terpisah: Bisa update satu service tanpa redeploy seluruh aplikasi. • Kinerja Baik: Koneksi ke DB biasanya langsung (native), tidak lewat banyak network hop.	• Decoupling Tinggi: Produser event tidak perlu tahu siapa yang menerima event. • Skalabilitas Tinggi: Mudah menambah consumer baru tanpa mengubah produser. • Responsif: Cocok untuk sistem real-time dan high-volume data.
Kekurangan (Cons)	• Sinkhole Anti-pattern: Request seringkali cuma “numpang lewat” di layer tengah tanpa logika apa-apa. • Monolithic: Biasanya dideploy sebagai satu kesatuan besar (sulit di-scale per fitur). • Ketergantungan: Perubahan di database sering merembet harus ubah code di semua layer di atasnya.	• Ketergantungan Database: Karena sering berbagi DB, perubahan skema tabel bisa merusak service lain. • Batas Service: Kadang bingung menentukan seberapa besar ukuran satu service (terlalu besar jadi monolith, terlalu kecil jadi ribet).	• Kompleksitas Tinggi: Sangat sudah untuk di-debug dan di-test (alur tidak linear). • Eventual Consistency: Data tidak langsung sinkron di semua tempat (ada jeda waktu). • Error Handling: Susah menangani kalau ada event yang gagal diproses di tengah jalan.
Implementasi	Aplikasi web standar, aplikasi internal perusahaan (Enterprise apps), MVP (Minimum Viable Product).	Migrasi dari Monolith ke Microservices (langkah transisi), aplikasi bisnis yang butuh pemisahan domain tapi timnya kecil.	Sistem notifikasi, aplikasi trading saham, IoT (sensor), sistem e-commerce skala raksasa (misal: order placed → trigger email, trigger gudang, trigger logistik secara paralel).
Cara Komunikasi	Sinkron (Synchronous): Request turun dari UI → Logic → DB, lalu return ke atas.	Hibrida: Biasanya kombinasi REST API (sinkron) untuk user, dan kadang pakai Queue untuk antar service.	Asinkron (Asynchronous): Menggunakan Message Broker (seperti Kafka, RabbitMQ) untuk melempar event “Fire and Forget”.

Tools Event Broker Populer

• RabbitMQ: Broker tradisional, matang, mendukung banyak protokol (AMQP, MQTT).

• Apache Kafka: Platform streaming event. Didesain untuk throughput sangat tinggi, persisten (menyimpan event), dan fault-tolerant. Menjadi standar de-facto untuk arsitektur berbasis event skala besar.

• Google Cloud Pub/Sub, AWS SQS/SNS: Layanan messaging terkelola di cloud.

Eksplorasi Mandiri

• Pikirkan proses checkout di e-commerce. (Misal: 1. Buat Order, 2. Proses Pembayaran, 3. Kurangi Stok, 4. Kirim Email Konfirmasi, 5. Siapkan Pengiriman).

• Bagaimana Anda mengimplementasikannya dengan model Request-Based (Orchestrator)? Apa masalahnya?

• Bagaimana Anda mengimplementasikannya dengan model Event-Based? (Misal: event “OrderCreated” memicu 4 processor berbeda secara independen).