(0275) 2974 127
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.
Salah satu pendekatan yang dapat digunakan untuk kebutuhan tersebut adalah Event-Driven Architecture (EDA) atau arsitektur berbasis event. 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.
EDA banyak digunakan dalam aplikasi terdistribusi, microservices, pemrosesan data, IoT, integrasi aplikasi, dan berbagai sistem yang membutuhkan pemrosesan event dengan jeda waktu yang rendah.
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.
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 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:
OrderCreated
PaymentCompleted
UserRegistered
ShipmentDispatched
Nama tersebut menggambarkan kejadian yang sudah berlangsung, bukan permintaan agar suatu tindakan dilakukan. Sebagai contoh, ketika pelanggan berhasil melakukan pembayaran, sistem dapat menghasilkan event: PaymentCompleted
Event tersebut kemudian dapat diproses oleh layanan lain yang membutuhkan informasi tersebut.
Misalnya:
PaymentCompleted
|
+----> Order Service
|
+----> Notification Service
|
+----> Analytics Service
Diagram tersebut merupakan ilustrasi arsitektur, bukan ketentuan bahwa setiap sistem pembayaran harus menggunakan desain yang sama.
Salah satu karakteristik penting EDA adalah adanya pemisahan atau decoupling 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.
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:
{
"eventType": "OrderCreated",
"orderId": "ORD-12345",
"customerId": "CUST-001",
"timestamp": "2026-08-08T10:00:00Z"
}
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.
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.
Event dan command merupakan dua konsep yang sering muncul dalam sistem terdistribusi, tetapi keduanya memiliki tujuan berbeda.
CreateOrder ProcessPayment SendNotification
OrderCreated PaymentCompleted NotificationSent
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, ProcessPayment lebih tepat dipahami sebagai perintah, sedangkan PaymentCompleted merupakan pemberitahuan bahwa pembayaran telah selesai.
Secara umum, EDA terdiri dari beberapa komponen utama yang saling berhubungan.
1. Event Producer
Event producer adalah komponen yang menghasilkan atau menerbitkan event. Producer dapat berupa:
Contohnya, Order Service menghasilkan event OrderCreated setelah sebuah pesanan berhasil dibuat. Producer tidak perlu mengetahui seluruh consumer yang akan menggunakan event tersebut. Pemisahan ini merupakan salah satu karakteristik penting EDA.
2. Event Consumer
Event consumer adalah komponen yang menerima dan memproses event. Satu jenis event dapat diproses oleh beberapa consumer untuk kebutuhan yang berbeda. Misalnya:
OrderCreated
|
+----> Inventory Service
|
+----> Notification Service
|
+----> Analytics Service
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.
3. Event Channel
Event channel 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:
Terminologi dan kemampuan masing-masing teknologi berbeda sehingga implementasinya harus mengacu pada dokumentasi platform yang digunakan.
4. Event Schema
Event schema mendefinisikan struktur data yang dibawa oleh event. Contohnya:
eventId
eventType
timestamp
source
entityId
payload
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.
Alur EDA secara sederhana dapat digambarkan seperti berikut:
Event Producer
|
v
Event Channel
|
+------> Consumer A
|
+------> Consumer B
|
+------> Consumer C
Customer membuat pesanan
OrderCreated
Event dapat membawa informasi yang dibutuhkan consumer sesuai desain sistem.OrderCreated
|
+----> Inventory Service
|
+----> Notification Service
|
+----> Analytics Service
Tidak , EDA sering menggunakan komunikasi asynchronous, 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:
Producer
|
v
Event
|
v
Consumer
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.
EDA dapat menggunakan beberapa model komunikasi, termasuk publish-subscribe dan event streaming.
1. Publish-Subscribe
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:
OrderCreated
|
v
Event System
| | |
v v v
Stock Email Analytics
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.
2. Event Streaming
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.
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.
Dalam pola request-response, satu komponen mengirim permintaan kepada komponen lain dan menunggu respons. Contohnya:
Order Service
|
| Request
v
Payment Service
|
| Response
v
Order Service
Order Service perlu mengetahui endpoint atau mekanisme komunikasi Payment Service.
Dalam pendekatan event-driven, alurnya dapat berupa:
Order Service
|
| PaymentCompleted
v
Event Channel
|
+----> Notification Service
|
+----> Analytics Service
|
+----> Order Service
Pendekatan event-driven dapat mengurangi ketergantungan langsung antara producer dan consumer.
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.
EDA dapat memberikan sejumlah keuntungan jika diterapkan pada kebutuhan yang sesuai.
1. Mengurangi Coupling Antarkomponen
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.
2. Memudahkan Penambahan Consumer
Ketika event yang relevan sudah tersedia, consumer baru dapat ditambahkan untuk kebutuhan tertentu tanpa harus mengubah seluruh producer. Misalnya:
OrderCompleted
|
+----> Notification
|
+----> Analytics
|
+----> Loyalty
Consumer baru dapat menggunakan event yang sama sesuai kebutuhan.
3. Mendukung Skalabilitas
EDA dapat membantu sistem melakukan scaling pada komponen yang memproses event secara independen. Namun, EDA tidak otomatis membuat aplikasi scalable. 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.
4. Mendukung Pemrosesan dengan Jeda Rendah
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.
5. Mendukung Integrasi Banyak Sistem
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.
Di balik fleksibilitasnya, EDA juga memiliki sejumlah konsekuensi yang harus diperhitungkan.
1. Kompleksitas Lebih Tinggi
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:
OrderCreated
↓
PaymentCompleted
↓
OrderConfirmed
↓
ShipmentCreated
Jika terjadi kegagalan pada salah satu tahap, developer perlu mengetahui event dan consumer mana yang bermasalah.
2. Eventual Consistency
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 PaymentCompleted. Dalam periode tersebut, kedua layanan dapat memiliki keadaan yang belum sepenuhnya sinkron. Kondisi ini dikenal sebagai eventual consistency.
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.
3. Event Ordering
Urutan event menjadi penting ketika urutan kejadian memengaruhi hasil pemrosesan. Misalnya:
OrderCreated
OrderCancelled
Consumer mungkin perlu mengetahui bahwa OrderCreated terjadi sebelum OrderCancelled.
Namun, jaminan ordering tidak sama pada semua teknologi. 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.
4. Duplicate Event dan Idempotency
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, yaitu pemrosesan ulang event yang sama tidak menyebabkan efek samping yang tidak diinginkan.
Contohnya, sistem tidak seharusnya mencatat pembayaran dua kali hanya karena event PaymentCompleted 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.
5. Debugging Lebih Sulit
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.
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.
6. Event Schema Evolution
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.
7. Penanganan Error Lebih Kompleks
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), tergantung teknologi yang digunakan. Namun, retry harus dirancang hati-hati. Pemrosesan ulang yang tidak terkontrol dapat menyebabkan duplicate processing atau beban tambahan pada sistem.
EDA dapat diterapkan menggunakan beberapa pola. Salah satu pembagian yang sering digunakan adalah event notification dan event-carried state transfer.
Event Notification
Dalam event notification, event terutama digunakan untuk memberi tahu consumer bahwa sesuatu telah terjadi. Contohnya: OrderCreated
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.
Event-Carried State Transfer
Dalam pola event-carried state transfer, 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.
Event Sourcing
Event Sourcing 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.
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.
E-commerce merupakan salah satu contoh domain yang dapat memanfaatkan event-driven architecture. Misalnya pelanggan melakukan checkout:
Customer
|
v
Order Service
|
v
OrderCreated
|
v
Event Channel
|
+----> Inventory Service
|
+----> Notification Service
|
+----> Analytics Service
Setelah pembayaran selesai, sistem dapat menghasilkan:
PaymentCompleted
Event tersebut kemudian dapat digunakan oleh layanan yang membutuhkan informasi pembayaran.
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.
IoT merupakan salah satu domain yang cocok untuk pemrosesan event dalam jumlah besar. Misalnya perangkat sensor menghasilkan event: TemperatureMeasured
Event tersebut dapat diproses oleh beberapa komponen:
IoT Device
|
v
TemperatureMeasured
|
+----> Monitoring Service
|
+----> Alert Service
|
+----> Data Processing
|
+----> Analytics
Microsoft Azure menyebut IoT sebagai salah satu skenario yang dapat membutuhkan ingestion event dengan volume dan throughput tinggi.
Ketika perangkat menghasilkan event dalam jumlah besar, sistem perlu dirancang agar event channel dan consumer mampu menangani karakteristik workload tersebut.
Sistem finansial juga dapat menggunakan event untuk merepresentasikan aktivitas transaksi. Contohnya:
TransactionInitiated
TransactionAuthorized
TransactionCompleted
TransactionFailed
Event tersebut dapat digunakan oleh komponen lain untuk melakukan proses yang relevan.
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.
EDA merupakan gaya arsitektur, bukan satu produk atau teknologi tertentu. Implementasinya dapat menggunakan berbagai platform.
1. Apache Kafka
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.
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.
2. RabbitMQ
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.
3. Amazon EventBridge
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.
4. Google Cloud Pub/Sub
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.
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.
EDA dan microservices merupakan dua konsep yang berbeda tetapi dapat digunakan secara bersamaan. Microservices merupakan pendekatan untuk membagi aplikasi menjadi sejumlah layanan dengan tanggung jawab tertentu. Sementara itu, Event-Driven Architecture merupakan gaya arsitektur yang menggunakan event sebagai bagian penting dari komunikasi dan pemrosesan antar komponen. Microservices dapat berkomunikasi menggunakan:
REST
gRPC
Message
Event
atau kombinasi beberapa mekanisme tersebut. Contohnya:
Order Service
|
+---- REST ----> Payment Service
|
+---- Event ---> Event Channel
|
+----> Inventory Service
+----> Notification Service
Jadi, microservices tidak sama dengan EDA, dan menggunakan microservices tidak secara otomatis berarti sistem harus menggunakan EDA.
Message queue merupakan mekanisme atau teknologi messaging, sedangkan EDA merupakan pendekatan arsitektur yang lebih luas. Sederhananya:
Message Queue → mekanisme komunikasi pesan
Event-Driven Architecture → gaya arsitektur yang menggunakan event sebagai bagian penting dari interaksi sistem
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.
EDA layak dipertimbangkan ketika sistem memiliki karakteristik seperti:
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.
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.
Penerapan EDA perlu disesuaikan dengan kebutuhan sistem. Beberapa prinsip berikut dapat membantu.
Gunakan Nama Event yang Jelas
Nama event sebaiknya menggambarkan kejadian yang telah terjadi. Contohnya:
UserRegistered
OrderCreated
PaymentCompleted
ShipmentDispatched
Penamaan yang konsisten membantu producer dan consumer memahami kontrak event.
Tentukan Event Berdasarkan Domain
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.
Rancang Schema dengan Memperhatikan Evolusi
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.
Terapkan Idempotency
Consumer sebaiknya mempertimbangkan kemungkinan event diproses ulang. Idempotency membantu mencegah efek samping yang tidak diinginkan ketika event yang sama diproses lebih dari satu kali.
Tentukan Kebutuhan Ordering
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.
Siapkan Retry dan Penanganan Kegagalan
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.
Terapkan Observability Sejak Awal
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.
Perhatikan Keamanan Data dalam Event
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.
Sebelum menerapkan Event-Driven Architecture, tim perlu mengevaluasi beberapa aspek.
Dengan pendekatan tersebut, EDA dapat digunakan secara terukur dan tidak sekadar diterapkan karena mengikuti tren teknologi.
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.
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. Jika membutuhkan layanan hosting untuk website, Hosteko Hosting Indonesia juga dapat menjadi salah satu pilihan yang dapat dipertimbangkan.
Cara Membuat Sitemap XML untuk Website agar Mudah Diindeks Google Sitemap XML merupakan salah satu…
Setelah memahami pengertian, perbedaan, serta kelebihan dan kekurangan masing-masing strategi pemasaran, pertanyaan yang sering muncul…
Setelah memahami pengertian churn rate pada bagian sebelumnya, langkah berikutnya adalah mengetahui bagaimana cara mengukurnya.…
Dalam menjalankan bisnis, mendapatkan pelanggan baru memang penting. Namun, mempertahankan pelanggan yang sudah ada tidak…
Di era digital, keberhasilan sebuah bisnis tidak hanya ditentukan oleh jumlah pelanggan yang berhasil diperoleh,…
Keamanan siber telah menjadi salah satu prioritas utama bagi perusahaan di era digital. Seiring meningkatnya…