Perkembangan aplikasi digital membuat sistem perangkat lunak harus mampu menangani berbagai aktivitas secara cepat dan terdistribusi. Ketika pengguna melakukan pembayaran, membuat pesanan, mengubah data, mengunggah file, atau ketika perangkat IoT mengirimkan informasi, aplikasi perlu merespons kejadian tersebut dan meneruskannya ke komponen lain yang membutuhkan informasi.<\/p>\n
Salah satu pendekatan yang dapat digunakan untuk kebutuhan tersebut adalah Event-Driven Architecture (EDA) <\/em>atau arsitektur berbasis event<\/em>. Pendekatan ini menjadikan event sebagai bagian penting dalam komunikasi antarkomponen sistem. Ketika sebuah kejadian terjadi, sistem dapat menghasilkan event yang kemudian diterima dan diproses oleh komponen lain.<\/p>\n EDA banyak digunakan dalam aplikasi terdistribusi, microservices, pemrosesan data, IoT, integrasi aplikasi, dan berbagai sistem yang membutuhkan pemrosesan event dengan jeda waktu yang rendah.<\/p>\n Namun, Event-Driven Architecture bukan sekadar penggunaan message broker. EDA mencakup cara sistem menghasilkan, menyalurkan, memproses, dan mengelola event. Karena itu, penerapannya juga memiliki konsekuensi seperti eventual consistency, pengelolaan urutan event, penanganan kegagalan, observability, serta perubahan schema.<\/p>\n Event-Driven Architecture adalah gaya arsitektur perangkat lunak yang menggunakan event untuk mengomunikasikan perubahan atau kejadian kepada komponen lain yang berkepentingan. Dalam EDA, terdapat komponen yang menghasilkan event, komponen yang menerima dan memproses event, serta mekanisme atau event channel<\/em> yang menyalurkan event dari producer kepada consumer. Event channel dapat diimplementasikan menggunakan berbagai teknologi, termasuk event broker atau layanan ingestion, tergantung kebutuhan sistem. Event sendiri dapat dipahami sebagai catatan bahwa sesuatu telah terjadi. Contohnya:<\/p>\n Nama tersebut menggambarkan kejadian yang sudah berlangsung, bukan permintaan agar suatu tindakan dilakukan. Sebagai contoh, ketika pelanggan berhasil melakukan pembayaran, sistem dapat menghasilkan event: Event tersebut kemudian dapat diproses oleh layanan lain yang membutuhkan informasi tersebut.<\/p>\n Misalnya:<\/p>\n Diagram tersebut merupakan ilustrasi arsitektur, bukan ketentuan bahwa setiap sistem pembayaran harus menggunakan desain yang sama.<\/p>\n Salah satu karakteristik penting EDA adalah adanya pemisahan atau decoupling<\/strong> antara producer dan consumer. Producer tidak harus mengetahui secara langsung seluruh consumer yang menggunakan event tersebut. Hal ini memungkinkan komponen berkembang dan diskalakan secara lebih independen, meskipun tetap membutuhkan desain yang tepat agar kompleksitas sistem dapat dikendalikan.<\/p>\n Event adalah informasi yang merepresentasikan suatu kejadian atau perubahan yang telah terjadi. Dalam dokumentasi Apache Kafka, event dijelaskan sebagai catatan bahwa sesuatu telah terjadi dalam dunia atau bisnis. Event dapat memiliki informasi seperti key, value, timestamp, dan metadata tambahan. Contoh event sederhana:<\/p>\n Contoh tersebut hanya merupakan ilustrasi struktur event. Struktur sebenarnya harus disesuaikan dengan kebutuhan domain, kontrak data, dan teknologi yang digunakan. Event dapat membawa data yang diperlukan consumer atau hanya membawa informasi tertentu seperti identifier yang kemudian digunakan consumer untuk mengambil data tambahan.<\/p>\n Microsoft Azure menjelaskan bahwa kedua pendekatan tersebut memiliki trade-off. Payload yang lengkap dapat mengurangi kebutuhan query tambahan, tetapi dapat memperbesar ukuran data dan menambah kompleksitas konsistensi serta versioning. Sebaliknya, payload yang hanya membawa key dapat menjaga satu sumber data utama, tetapi consumer mungkin perlu melakukan query tambahan.<\/p>\n Event dan command merupakan dua konsep yang sering muncul dalam sistem terdistribusi, tetapi keduanya memiliki tujuan berbeda.<\/p>\n Perbedaan ini penting karena event biasanya bersifat informatif. Producer memberitahukan fakta yang terjadi, sementara consumer menentukan apakah event tersebut relevan dan tindakan apa yang perlu dilakukan. Dengan demikian, Secara umum, EDA terdiri dari beberapa komponen utama yang saling berhubungan.<\/p>\n 1. Event Producer<\/span><\/p>\n Event producer<\/em> adalah komponen yang menghasilkan atau menerbitkan event. Producer dapat berupa:<\/p>\n Contohnya, Order Service menghasilkan event 2. Event Consumer<\/span><\/p>\n Event consumer <\/em>adalah komponen yang menerima dan memproses event. Satu jenis event dapat diproses oleh beberapa consumer untuk kebutuhan yang berbeda. Misalnya:<\/p>\n Inventory Service dapat menggunakan event untuk memproses stok, Notification Service untuk mengirim pemberitahuan, dan Analytics Service untuk kebutuhan analisis. Namun, pembagian tersebut hanyalah contoh. Consumer yang sebenarnya digunakan bergantung pada kebutuhan bisnis dan desain aplikasi.<\/p>\n 3. Event Channel<\/span><\/p>\n Event channel<\/em> adalah mekanisme yang menyalurkan event dari producer kepada consumer. Microsoft Azure menjelaskan bahwa event channel sering diimplementasikan menggunakan event broker atau layanan ingestion. Jadi, penggunaan broker bukan satu-satunya bentuk implementasi EDA. Dalam implementasi tertentu, event channel dapat berupa:<\/p>\n Terminologi dan kemampuan masing-masing teknologi berbeda sehingga implementasinya harus mengacu pada dokumentasi platform yang digunakan.<\/p>\n 4. Event Schema<\/span><\/p>\n Event schema<\/em> mendefinisikan struktur data yang dibawa oleh event. Contohnya:<\/p>\n Field tersebut hanya contoh umum, bukan struktur yang wajib digunakan pada semua sistem. Schema menjadi penting ketika banyak producer dan consumer dikembangkan secara independen. Jika producer mengubah struktur event tanpa mempertimbangkan consumer yang masih menggunakan versi sebelumnya, perubahan tersebut dapat menyebabkan kegagalan pemrosesan. Karena itu, strategi schema versioning dan kompatibilitas perlu dipikirkan sejak awal.<\/p>\n Alur EDA secara sederhana dapat digambarkan seperti berikut:<\/p>\n Tidak , EDA sering menggunakan komunikasi asynchronous<\/em>, terutama ketika producer tidak perlu menunggu consumer menyelesaikan pemrosesan sebelum melanjutkan pekerjaannya. Microsoft Azure juga menjelaskan bahwa arsitektur event-driven terutama mengandalkan komunikasi asynchronous, tetapi pola request-response tetap dapat digunakan dalam sistem event-driven ketika sebuah proses membutuhkan respons langsung. Dalam pemrosesan asynchronous:<\/p>\n Producer dapat menerbitkan event tanpa harus menunggu seluruh proses consumer selesai. Model ini berguna untuk proses yang dapat dikerjakan secara terpisah. Namun, jika sebuah proses membutuhkan jawaban langsung, komunikasi request-response tetap dapat digunakan. Dengan demikian, EDA tidak berarti seluruh komunikasi aplikasi harus diubah menjadi asynchronous.<\/p>\n EDA dapat menggunakan beberapa model komunikasi, termasuk publish-subscribe<\/em> dan event streaming.<\/em><\/p>\n 1. Publish-Subscribe<\/span><\/p>\n Dalam model publish-subscribe, producer menerbitkan event dan infrastruktur messaging mendistribusikannya kepada subscriber yang sesuai. Jika terdapat beberapa subscriber yang berbeda, satu event dapat digunakan oleh beberapa konsumen untuk kebutuhan yang berbeda. Contohnya:<\/p>\n Karakteristik penyimpanan event bergantung pada teknologi yang digunakan. Pada sistem publish-subscribe tertentu, event tidak tersedia sebagai log historis untuk subscriber baru. Karena itu, karakteristik replay atau retention tidak boleh digeneralisasikan ke seluruh teknologi publish-subscribe.<\/p>\n 2. Event Streaming<\/span><\/p>\n Pada event streaming, event dapat dicatat dalam stream atau log sehingga consumer dapat membaca event sesuai posisi yang tersedia pada sistem. Apache Kafka, misalnya, menyimpan event dalam topic dan membagi topic menjadi partition.<\/p>\n Kafka mempertahankan urutan event di dalam masing-masing partition, bukan urutan global untuk seluruh partition dalam sebuah topic. Model event streaming berguna untuk kebutuhan seperti pemrosesan data secara berkelanjutan, analitik streaming, dan sistem yang membutuhkan kemampuan membaca atau memproses kembali event sesuai kemampuan platform.<\/p>\n Dalam pola request-response, satu komponen mengirim permintaan kepada komponen lain dan menunggu respons. Contohnya:<\/p>\n Order Service perlu mengetahui endpoint atau mekanisme komunikasi Payment Service.<\/em><\/p>\n Dalam pendekatan event-driven, alurnya dapat berupa:<\/p>\n Pendekatan event-driven dapat mengurangi ketergantungan langsung antara producer dan consumer.<\/em><\/p>\n Namun, request-response tidak lebih buruk daripada EDA. Keduanya digunakan untuk kebutuhan yang berbeda. Request-response cocok ketika aplikasi membutuhkan respons langsung. EDA lebih sesuai ketika perubahan dapat dipublikasikan sebagai event dan diproses oleh komponen lain tanpa hubungan langsung yang ketat. Dalam aplikasi nyata, kedua pendekatan tersebut juga dapat digunakan secara bersamaan.<\/p>\n EDA dapat memberikan sejumlah keuntungan jika diterapkan pada kebutuhan yang sesuai.<\/p>\n 1. Mengurangi Coupling Antarkomponen<\/span><\/p>\n Producer tidak harus mengetahui seluruh consumer yang menerima event. Hal ini dapat mengurangi integrasi point-to-point dan memberikan ruang bagi consumer untuk berkembang secara independen.<\/p>\n 2. Memudahkan Penambahan Consumer<\/span><\/p>\n Ketika event yang relevan sudah tersedia, consumer baru dapat ditambahkan untuk kebutuhan tertentu tanpa harus mengubah seluruh producer. Misalnya:<\/p>\n Consumer baru dapat menggunakan event yang sama sesuai kebutuhan.<\/p>\n 3. Mendukung Skalabilitas<\/span><\/p>\n EDA dapat membantu sistem melakukan scaling pada komponen yang memproses event secara independen. Namun, EDA tidak otomatis membuat aplikasi scalable<\/em>. Kemampuan scaling tetap bergantung pada desain keseluruhan sistem, termasuk event channel, consumer, database, infrastruktur, partitioning, concurrency, serta karakteristik workload. Microsoft Azure menyebut decoupling producer dan consumer sebagai salah satu kondisi yang dapat mendukung tujuan independent scalability dan reliability.<\/p>\n 4. Mendukung Pemrosesan dengan Jeda Rendah<\/span><\/p>\n Event dapat diproses segera setelah diterima, sehingga EDA sesuai untuk kebutuhan yang memerlukan pemrosesan real-time atau near-real-time. Contohnya antara lain pemrosesan event IoT, analitik streaming, dan sistem yang harus merespons perubahan secara cepat.<\/p>\n 5. Mendukung Integrasi Banyak Sistem<\/span><\/p>\n Event dapat menjadi mekanisme integrasi antara berbagai layanan dan aplikasi. Sebagai contoh, satu event transaksi dapat digunakan oleh layanan pesanan, notifikasi, analitik, dan sistem lainnya tanpa setiap layanan harus membuat integrasi langsung dengan producer.<\/p>\n Di balik fleksibilitasnya, EDA juga memiliki sejumlah konsekuensi yang harus diperhitungkan.<\/p>\n 1. Kompleksitas Lebih Tinggi<\/span><\/p>\n Sistem event-driven dapat lebih sulit dipahami dibandingkan alur request-response sederhana. Satu event dapat memicu beberapa proses lain dan bahkan menghasilkan event baru. Contohnya:<\/p>\n Jika terjadi kegagalan pada salah satu tahap, developer perlu mengetahui event dan consumer mana yang bermasalah.<\/p>\n 2. Eventual Consistency<\/span><\/p>\n Pada sistem asynchronous, perubahan data di beberapa layanan tidak selalu terjadi pada waktu yang sama. Misalnya Order Service sudah mengetahui pembayaran berhasil, tetapi Notification Service belum selesai memproses event Eventual consistency bukan kesalahan implementasi secara otomatis. Ini dapat menjadi trade-off arsitektural yang memang diterima pada sistem tertentu. Namun, sistem harus dirancang agar dapat menangani kondisi ketika data belum langsung konsisten.<\/p>\n 3. Event Ordering<\/span><\/p>\n Urutan event menjadi penting ketika urutan kejadian memengaruhi hasil pemrosesan. Misalnya:<\/p>\n Consumer mungkin perlu mengetahui bahwa Namun, jaminan ordering tidak sama pada semua teknologi<\/em>. Sebagai contoh, Apache Kafka menjamin urutan dalam sebuah partition, bukan urutan global antarseluruh partition. Karena itu, kebutuhan ordering harus ditentukan sejak awal dan disesuaikan dengan teknologi yang digunakan.<\/p>\n 4. Duplicate Event dan Idempotency<\/span><\/p>\n Dalam sistem distributed messaging, consumer perlu mempertimbangkan kemungkinan menerima atau memproses event lebih dari satu kali, tergantung mekanisme delivery dan implementasi platform. Karena itu, operasi tertentu perlu dirancang idempotent<\/em>, yaitu pemrosesan ulang event yang sama tidak menyebabkan efek samping yang tidak diinginkan.<\/p>\n Contohnya, sistem tidak seharusnya mencatat pembayaran dua kali hanya karena event 5. Debugging Lebih Sulit<\/span><\/p>\n Pada sistem synchronous, developer dapat mengikuti satu request dari awal hingga response. Dalam EDA, satu proses bisnis dapat melibatkan producer, event channel, beberapa consumer, dan event lanjutan. Karena itu, observability menjadi bagian penting dari desain.<\/p>\n Logging, metrics, distributed tracing, dan correlation ID dapat membantu menghubungkan event dan proses yang berasal dari transaksi yang sama. Microsoft Azure secara khusus merekomendasikan correlation ID untuk membantu melacak operasi lintas komponen yang terpisah dan asynchronous.<\/p>\n 6. Event Schema Evolution<\/span><\/p>\n Producer dan consumer dapat dikembangkan dan dideploy secara independen. Masalah dapat muncul ketika producer mengubah struktur event sedangkan consumer masih menggunakan schema lama. Karena itu, sistem perlu mempertimbangkan strategi versioning dan kompatibilitas schema sejak awal.<\/p>\n 7. Penanganan Error Lebih Kompleks<\/span><\/p>\n Pada sistem asynchronous, error tidak selalu dapat langsung dikembalikan kepada producer seperti pada request-response. Salah satu pendekatan yang dapat digunakan adalah retry dan mekanisme dead-letter queue (DLQ)<\/em>, tergantung teknologi yang digunakan. Namun, retry harus dirancang hati-hati. Pemrosesan ulang yang tidak terkontrol dapat menyebabkan duplicate processing atau beban tambahan pada sistem.<\/p>\n EDA dapat diterapkan menggunakan beberapa pola. Salah satu pembagian yang sering digunakan adalah event notification dan event-carried state transfer.<\/p>\n Event Notification<\/span><\/p>\n Dalam event notification<\/em>, event terutama digunakan untuk memberi tahu consumer bahwa sesuatu telah terjadi. Contohnya: Consumer mengetahui bahwa order telah dibuat dan dapat mengambil tindakan yang sesuai. Event notification dapat membantu mengurangi ketergantungan langsung antara layanan, tetapi consumer mungkin perlu mengambil data tambahan dari sumber lain jika informasi dalam event belum cukup.<\/p>\n Event-Carried State Transfer<\/span><\/p>\n Dalam pola event-carried state transfer,<\/em> event membawa data yang lebih lengkap sehingga consumer dapat menggunakan informasi tersebut untuk memperbarui state lokalnya. Martin Fowler menjelaskan pola ini sebagai pendekatan ketika penerima event dapat mempertahankan salinan data yang diperlukan sehingga tidak perlu selalu menghubungi sistem sumber. Pendekatan tersebut dapat mengurangi ketergantungan runtime, tetapi menambah kompleksitas dalam menjaga state dan membawa lebih banyak data.<\/p>\n Event Sourcing<\/span><\/p>\n Event Sourcing<\/em> sering dikaitkan dengan EDA, tetapi keduanya bukan konsep yang sama. Event Sourcing merupakan pola penyimpanan data yang menyimpan rangkaian perubahan atau tindakan sebagai event dalam penyimpanan append-only, kemudian menggunakan rangkaian tersebut sebagai dasar untuk membangun state objek atau domain.<\/p>\n Microsoft Azure menekankan bahwa Event Sourcing merupakan pola yang kompleks dan memiliki trade-off terkait penyimpanan data, concurrency, perubahan schema, query, serta migrasi. Karena itu, Event Sourcing tidak perlu digunakan hanya karena sebuah sistem telah menggunakan EDA.<\/p>\n E-commerce merupakan salah satu contoh domain yang dapat memanfaatkan event-driven architecture. Misalnya pelanggan melakukan checkout:<\/p>\n Setelah pembayaran selesai, sistem dapat menghasilkan:<\/p>\n Event tersebut kemudian dapat digunakan oleh layanan yang membutuhkan informasi pembayaran.<\/p>\n Contoh ini menunjukkan bagaimana satu kejadian dapat menjadi pemicu bagi beberapa proses yang berbeda. Namun, desain aktual sistem e-commerce dapat berbeda. Tidak semua proses harus menggunakan event, dan beberapa proses mungkin lebih tepat menggunakan request-response.<\/p>\n IoT merupakan salah satu domain yang cocok untuk pemrosesan event dalam jumlah besar. Misalnya perangkat sensor menghasilkan event: Event tersebut dapat diproses oleh beberapa komponen:<\/p>\n Microsoft Azure menyebut IoT sebagai salah satu skenario yang dapat membutuhkan ingestion event dengan volume dan throughput tinggi.<\/p>\n Ketika perangkat menghasilkan event dalam jumlah besar, sistem perlu dirancang agar event channel dan consumer mampu menangani karakteristik workload tersebut.<\/p>\n Sistem finansial juga dapat menggunakan event untuk merepresentasikan aktivitas transaksi. Contohnya:<\/p>\n Event tersebut dapat digunakan oleh komponen lain untuk melakukan proses yang relevan.<\/p>\n Namun, sistem finansial memiliki kebutuhan khusus terkait keamanan, audit, konsistensi, reliability, dan regulasi. Karena itu, contoh event di atas hanya merupakan ilustrasi konsep dan bukan representasi desain wajib untuk sistem perbankan atau layanan finansial tertentu.<\/p>\n EDA merupakan gaya arsitektur, bukan satu produk atau teknologi tertentu. Implementasinya dapat menggunakan berbagai platform.<\/p>\n 1. Apache Kafka<\/span><\/p>\n Apache Kafka merupakan platform event streaming yang menggunakan konsep seperti producer, consumer, topic, partition, dan consumer group. Dalam Kafka, event disimpan di topic dan topic dibagi menjadi partition. Urutan event dijamin dalam konteks partition, sehingga kebutuhan ordering harus mempertimbangkan desain partitioning.<\/p>\n Kafka juga mendukung pola consumer group. Dalam satu consumer group, sebuah event pada partition diproses oleh satu consumer instance dalam group tersebut pada suatu waktu, sehingga consumer group dapat digunakan untuk pembagian beban pemrosesan.<\/p>\n 2. RabbitMQ<\/span><\/p>\n RabbitMQ merupakan message broker yang dapat digunakan untuk komunikasi berbasis pesan. RabbitMQ mendukung berbagai pola messaging dan menyediakan konsep seperti exchange dan queue. Detail routing dan delivery bergantung pada konfigurasi serta model protokol yang digunakan. RabbitMQ dapat menjadi salah satu pilihan untuk kebutuhan messaging, tetapi pemilihannya tetap harus disesuaikan dengan kebutuhan sistem dan karakteristik workload.<\/p>\n 3. Amazon EventBridge<\/span><\/p>\n Amazon EventBridge adalah layanan AWS yang menggunakan event untuk menghubungkan komponen aplikasi. Dalam EventBridge, event bus bertindak sebagai router yang menerima event dan meneruskannya ke target berdasarkan rule. Rule dapat mencocokkan event berdasarkan pola tertentu dan kemudian mengirimkan event yang sesuai ke target. EventBridge merupakan salah satu contoh layanan terkelola untuk membangun aplikasi berbasis event, tetapi konsep EDA tidak terbatas pada AWS atau EventBridge.<\/p>\n 4. Google Cloud Pub\/Sub<\/span><\/p>\n Google Cloud Pub\/Sub merupakan layanan messaging asynchronous yang memisahkan publisher dari subscriber. Konsep utamanya mencakup topic, subscription, publisher, subscriber, message, dan schema. Satu topic dapat memiliki beberapa subscription sehingga pesan dapat digunakan dalam pola fan-out, sedangkan beberapa subscriber dalam subscription dapat digunakan untuk pembagian beban pemrosesan.<\/p>\n Google Cloud juga mendokumentasikan bahwa Pub\/Sub menawarkan at-least-once delivery dan fitur terkait ordering serta exactly-once delivery sesuai kemampuan dan konfigurasi layanan. Karena karakteristik delivery merupakan detail platform, informasi tersebut tidak boleh digeneralisasikan sebagai karakteristik semua sistem EDA.<\/p>\n EDA dan microservices merupakan dua konsep yang berbeda tetapi dapat digunakan secara bersamaan. Microservices <\/em>merupakan pendekatan untuk membagi aplikasi menjadi sejumlah layanan dengan tanggung jawab tertentu. Sementara itu, Event-Driven Architecture<\/em> merupakan gaya arsitektur yang menggunakan event sebagai bagian penting dari komunikasi dan pemrosesan antar komponen. Microservices dapat berkomunikasi menggunakan:<\/p>\n atau kombinasi beberapa mekanisme tersebut. Contohnya:<\/p>\n Jadi, microservices tidak sama dengan EDA<\/em>, dan menggunakan microservices tidak secara otomatis berarti sistem harus menggunakan EDA.<\/p>\n Message queue merupakan mekanisme atau teknologi messaging, sedangkan EDA merupakan pendekatan arsitektur yang lebih luas. Sederhananya:<\/p>\n Message Queue \u2192 mekanisme komunikasi pesan<\/em> Karena itu, message queue dapat digunakan sebagai bagian dari sistem event-driven, tetapi keberadaan message queue saja tidak cukup untuk mendefinisikan sebuah sistem sebagai EDA. Selain queue, sistem event-driven juga dapat menggunakan event bus atau event streaming platform, tergantung kebutuhan.<\/p>\n EDA layak dipertimbangkan ketika sistem memiliki karakteristik seperti:<\/p>\n EDA bukan solusi untuk semua jenis aplikasi. Microsoft Azure menyebut beberapa kondisi ketika EDA mungkin kurang sesuai, termasuk workflow request-response sederhana yang sudah dapat memenuhi kebutuhan latency dan throughput dengan komunikasi synchronous. Dalam situasi tersebut, overhead event broker, asynchronous error handling, dan eventual consistency mungkin tidak sebanding dengan manfaat yang diperoleh.<\/p>\n EDA juga perlu dipertimbangkan kembali ketika proses bisnis membutuhkan strong consistency lintas layanan dan tidak dapat menerima kondisi sementara ketika beberapa bagian sistem memiliki state berbeda. Selain itu, sistem event-driven membutuhkan kemampuan untuk mengelola distributed asynchronous systems. Jika tim belum siap menangani observability, debugging, error recovery, dan pengelolaan event, kompleksitas EDA dapat menjadi beban tambahan. Untuk aplikasi sederhana, arsitektur request-response biasa dapat menjadi pilihan yang lebih mudah dan sesuai.<\/p>\n Penerapan EDA perlu disesuaikan dengan kebutuhan sistem. Beberapa prinsip berikut dapat membantu.<\/p>\n Gunakan Nama Event yang Jelas<\/span><\/p>\n Nama event sebaiknya menggambarkan kejadian yang telah terjadi. Contohnya:<\/p>\n Penamaan yang konsisten membantu producer dan consumer memahami kontrak event.<\/p>\n Tentukan Event Berdasarkan Domain<\/span><\/p>\n Event sebaiknya merepresentasikan kejadian yang bermakna dalam domain bisnis. Hindari membuat event terlalu banyak tanpa alasan yang jelas. Microsoft Azure juga mengingatkan bahwa jumlah event yang terlalu banyak dapat membebani sistem dan membuat alur event sulit dianalisis. Sebaliknya, event yang terlalu umum dapat menyebabkan consumer melakukan pemrosesan yang tidak diperlukan.<\/p>\n Rancang Schema dengan Memperhatikan Evolusi<\/span><\/p>\n Schema event harus dirancang agar dapat berkembang. Perubahan schema perlu mempertimbangkan consumer yang mungkin masih menggunakan versi lama. Strategi versioning, kompatibilitas, dan dokumentasi schema sebaiknya ditentukan sejak awal.<\/p>\n Terapkan Idempotency<\/span><\/p>\n Consumer sebaiknya mempertimbangkan kemungkinan event diproses ulang. Idempotency membantu mencegah efek samping yang tidak diinginkan ketika event yang sama diproses lebih dari satu kali.<\/p>\n Tentukan Kebutuhan Ordering<\/span><\/p>\n Jangan mengasumsikan semua event harus diproses secara global berurutan. Tentukan terlebih dahulu apakah urutan penting untuk domain tertentu. Jika memang diperlukan, gunakan mekanisme ordering yang disediakan oleh teknologi yang dipilih.<\/p>\n Siapkan Retry dan Penanganan Kegagalan<\/span><\/p>\n Event yang gagal diproses dapat memerlukan retry. Namun, retry perlu memiliki batas dan strategi yang jelas agar tidak menciptakan loop atau membebani sistem. Untuk event yang tetap gagal setelah mekanisme pemulihan tertentu, dead-letter mechanism dapat digunakan apabila didukung dan sesuai dengan teknologi yang digunakan.<\/p>\n Terapkan Observability Sejak Awal<\/span><\/p>\n Logging dan monitoring sebaiknya tidak ditambahkan setelah sistem menjadi kompleks. Correlation ID dapat digunakan untuk menghubungkan event dengan proses bisnis yang sama di berbagai service. Distributed tracing juga dapat membantu memahami alur transaksi yang melewati beberapa komponen asynchronous.<\/p>\n Perhatikan Keamanan Data dalam Event<\/span><\/p>\n Event dapat dilihat oleh lebih dari satu komponen. Karena itu, jangan memasukkan data sensitif ke dalam event tanpa alasan dan kontrol keamanan yang tepat. Microsoft Azure secara khusus mengingatkan bahwa event dapat terlihat oleh beberapa komponen dalam workload, sehingga isi event perlu dipertimbangkan dari sisi potensi paparan informasi.<\/p>\n Sebelum menerapkan Event-Driven Architecture, tim perlu mengevaluasi beberapa aspek.<\/p>\n Dengan pendekatan tersebut, EDA dapat digunakan secara terukur dan tidak sekadar diterapkan karena mengikuti tren teknologi.<\/p>\n Event-Driven Architecture adalah gaya arsitektur perangkat lunak yang menggunakan event untuk mengomunikasikan kejadian atau perubahan antarkomponen. EDA dapat membantu mengurangi coupling, mendukung skalabilitas, serta memfasilitasi pemrosesan event secara asynchronous. Namun, penerapannya tetap perlu mempertimbangkan eventual consistency, event ordering, duplicate processing, schema evolution, error handling, dan observability.<\/p>\n Karena itu, EDA sebaiknya diterapkan berdasarkan kebutuhan bisnis dan karakteristik sistem, bukan sekadar mengikuti tren teknologi. Untuk menambah wawasan seputar teknologi, hosting, server, dan pengembangan website, kunjungi Blog Hosteko<\/strong><\/a><\/em>. Jika membutuhkan layanan hosting untuk website, Hosteko Hosting Indonesia<\/strong><\/em><\/a> juga dapat menjadi salah satu pilihan yang dapat dipertimbangkan.<\/p>\n\n\nApa Itu Event-Driven Architecture?<\/h2>\n
OrderCreated\r\nPaymentCompleted\r\nUserRegistered\r\nShipmentDispatched\r\n<\/code><\/pre>\nPaymentCompleted<\/code>
\n<\/code><\/p>\nPaymentCompleted\r\n |\r\n +----> Order Service\r\n |\r\n +----> Notification Service\r\n |\r\n +----> Analytics Service\r\n<\/code><\/pre>\nApa yang Dimaksud dengan Event?<\/h2>\n
{\r\n \"eventType\": \"OrderCreated\",\r\n \"orderId\": \"ORD-12345\",\r\n \"customerId\": \"CUST-001\",\r\n \"timestamp\": \"2026-08-08T10:00:00Z\"\r\n}\r\n<\/code><\/pre>\nPerbedaan Event dan Command<\/h2>\n
\n
\n<\/strong>Contohnya:<\/li>\n<\/ul>\n\n
CreateOrder\r\nProcessPayment\r\nSendNotification\r\n<\/code><\/pre>\n<\/blockquote>\n\n
\n
OrderCreated\r\nPaymentCompleted\r\nNotificationSent\r\n<\/code><\/pre>\n<\/blockquote>\nProcessPayment<\/code> lebih tepat dipahami sebagai perintah, sedangkan PaymentCompleted<\/code> merupakan pemberitahuan bahwa pembayaran telah selesai.<\/p>\nKomponen Utama Event-Driven Architecture<\/h2>\n
\n
OrderCreated<\/code> setelah sebuah pesanan berhasil dibuat. Producer tidak perlu mengetahui seluruh consumer yang akan menggunakan event tersebut. Pemisahan ini merupakan salah satu karakteristik penting EDA.<\/p>\nOrderCreated\r\n |\r\n +----> Inventory Service\r\n |\r\n +----> Notification Service\r\n |\r\n +----> Analytics Service\r\n<\/code><\/pre>\n\n
eventId\r\neventType\r\ntimestamp\r\nsource\r\nentityId\r\npayload\r\n<\/code><\/pre>\nBagaimana Cara Kerja Event-Driven Architecture?<\/h2>\n
Event Producer\r\n |\r\n v\r\nEvent Channel\r\n |\r\n +------> Consumer A\r\n |\r\n +------> Consumer B\r\n |\r\n +------> Consumer C\r\n<\/code><\/pre>\n\n
\n<\/strong>Proses dimulai ketika aktivitas tertentu terjadi. Misalnya pelanggan membuat pesanan.<\/li>\n<\/ul>\nCustomer membuat pesanan\r\n<\/code><\/pre>\n\n
\n<\/strong>Order Service kemudian menghasilkan event: OrderCreated
\n<\/code>Event dapat membawa informasi yang dibutuhkan consumer sesuai desain sistem.<\/li>\n<\/ul>\n\n
\n<\/strong>Event dikirim melalui event channel atau mekanisme distribusi yang digunakan. Teknologi yang digunakan dapat berbeda-beda, misalnya event bus, message broker, atau platform event streaming.<\/li>\n<\/ul>\n\n
\n<\/strong>Consumer yang berkepentingan menerima event tersebut. Contohnya:<\/li>\n<\/ul>\nOrderCreated\r\n |\r\n +----> Inventory Service\r\n |\r\n +----> Notification Service\r\n |\r\n +----> Analytics Service\r\n<\/code><\/pre>\n\n
\n<\/strong>Setiap consumer menjalankan proses sesuai tanggung jawabnya. Inventory Service dapat memproses perubahan stok, sedangkan Notification Service dapat mengirimkan pemberitahuan kepada pelanggan. Dengan model seperti ini, producer tidak perlu memanggil setiap consumer secara langsung.<\/li>\n<\/ul>\nApakah Event-Driven Architecture Selalu Asynchronous?<\/h2>\n
Producer\r\n |\r\n v\r\nEvent\r\n |\r\n v\r\nConsumer\r\n<\/code><\/pre>\nModel Publish-Subscribe dan Event Streaming<\/h2>\n
OrderCreated\r\n |\r\n v\r\nEvent System\r\n | | |\r\n v v v\r\nStock Email Analytics\r\n<\/code><\/pre>\nPerbedaan Event-Driven Architecture dan Request-Response<\/h2>\n
Order Service\r\n |\r\n | Request\r\n v\r\nPayment Service\r\n |\r\n | Response\r\n v\r\nOrder Service\r\n<\/code><\/pre>\nOrder Service\r\n |\r\n | PaymentCompleted\r\n v\r\nEvent Channel\r\n |\r\n +----> Notification Service\r\n |\r\n +----> Analytics Service\r\n |\r\n +----> Order Service\r\n<\/code><\/pre>\nKelebihan Event-Driven Architecture<\/h2>\n
OrderCompleted\r\n |\r\n +----> Notification\r\n |\r\n +----> Analytics\r\n |\r\n +----> Loyalty\r\n<\/code><\/pre>\nKekurangan dan Tantangan Event-Driven Architecture<\/h2>\n
OrderCreated\r\n \u2193\r\nPaymentCompleted\r\n \u2193\r\nOrderConfirmed\r\n \u2193\r\nShipmentCreated\r\n<\/code><\/pre>\nPaymentCompleted<\/code>. Dalam periode tersebut, kedua layanan dapat memiliki keadaan yang belum sepenuhnya sinkron. Kondisi ini dikenal sebagai eventual consistency. <\/em><\/p>\nOrderCreated\r\nOrderCancelled\r\n<\/code><\/pre>\nOrderCreated<\/code> terjadi sebelum OrderCancelled<\/code>.<\/p>\nPaymentCompleted<\/code> diproses ulang. Detail jaminan delivery berbeda antarplatform. Sebagai contoh, Google Cloud Pub\/Sub mendokumentasikan at-least-once delivery untuk pesan dan menyediakan fitur tertentu terkait ordering serta exactly-once delivery pada kondisi yang didukung platform.<\/p>\nPola Event-Driven Architecture<\/h2>\n
OrderCreated<\/code><\/p>\nContoh Event-Driven Architecture pada E-Commerce<\/h2>\n
Customer\r\n |\r\n v\r\nOrder Service\r\n |\r\n v\r\nOrderCreated\r\n |\r\n v\r\nEvent Channel\r\n |\r\n +----> Inventory Service\r\n |\r\n +----> Notification Service\r\n |\r\n +----> Analytics Service\r\n<\/code><\/pre>\nPaymentCompleted\r\n<\/code><\/pre>\nContoh Event-Driven Architecture pada IoT<\/h2>\n
TemperatureMeasured
\n<\/code><\/p>\nIoT Device\r\n |\r\n v\r\nTemperatureMeasured\r\n |\r\n +----> Monitoring Service\r\n |\r\n +----> Alert Service\r\n |\r\n +----> Data Processing\r\n |\r\n +----> Analytics\r\n<\/code><\/pre>\nContoh Event-Driven Architecture pada Sistem Finansial<\/h2>\n
TransactionInitiated\r\nTransactionAuthorized\r\nTransactionCompleted\r\nTransactionFailed\r\n<\/code><\/pre>\nTeknologi yang Dapat Digunakan untuk Event-Driven Architecture<\/h2>\n
Event-Driven Architecture dalam Microservices<\/h2>\n
REST\r\ngRPC\r\nMessage\r\nEvent\r\n<\/code><\/pre>\nOrder Service\r\n |\r\n +---- REST ----> Payment Service\r\n |\r\n +---- Event ---> Event Channel\r\n |\r\n +----> Inventory Service\r\n +----> Notification Service\r\n<\/code><\/pre>\nPerbedaan EDA dan Message Queue<\/h2>\n
\nEvent-Driven Architecture \u2192 gaya arsitektur yang menggunakan event sebagai bagian penting dari interaksi sistem<\/em><\/p><\/blockquote>\nKapan Sebaiknya Menggunakan Event-Driven Architecture?<\/h2>\n
\n
\n<\/strong>Jika satu kejadian harus digunakan oleh beberapa subsistem yang berbeda, event dapat membantu menghindari banyak integrasi point-to-point.<\/li>\n<\/ul>\n\n
\n<\/strong>EDA dapat digunakan ketika sistem perlu merespons perubahan dengan jeda waktu yang rendah.<\/li>\n<\/ul>\n\n
\n<\/strong>Event-driven architecture dapat mendukung kebutuhan seperti korelasi event, agregasi berdasarkan window waktu, atau analisis pola event.<\/li>\n<\/ul>\n\n
\n<\/strong>Skenario seperti IoT dan streaming data dapat menjadi kandidat yang sesuai karena sistem dapat dirancang untuk memproses event dalam jumlah besar.<\/li>\n<\/ul>\n\n
\n<\/strong>Jika producer dan consumer perlu dikembangkan, diskalakan, atau dikelola secara lebih independen, EDA dapat menjadi pilihan yang relevan.<\/li>\n<\/ul>\nKapan Event-Driven Architecture Tidak Diperlukan?<\/h2>\n
Best Practice Menerapkan Event-Driven Architecture<\/h2>\n
UserRegistered\r\nOrderCreated\r\nPaymentCompleted\r\nShipmentDispatched\r\n<\/code><\/pre>\nHal yang Perlu Dipertimbangkan Sebelum Mengadopsi EDA<\/h2>\n
\n
Kesimpulan<\/h2>\n