Dalam dunia pemrograman, berbagai pendekatan dan teknik dikembangkan untuk memudahkan pembuatan aplikasi yang lebih interaktif dan responsif. Salah satu teknik yang paling populer dan banyak digunakan saat ini adalah Pemrograman Berbasis Event-Driven (Event-Driven Programming). Teknik ini menjadi pondasi bagi banyak aplikasi modern, terutama yang melibatkan antarmuka pengguna (user interface) seperti aplikasi desktop, web, dan mobile. Pemrograman berbasis peristiwa memungkinkan aplikasi merespons berbagai aksi pengguna atau kejadian lain secara efisien, menjadikannya pilihan utama dalam pengembangan software yang dinamis.
Berbeda dengan pendekatan pemrograman tradisional yang mengikuti alur linear atau prosedural, pemrograman berbasis event memusatkan perhatiannya pada kejadian atau peristiwa (event) tertentu. Dalam konteks ini, program tidak hanya menunggu hingga perintah selesai dieksekusi, melainkan siap merespons berbagai interaksi secara real-time. Misalnya, ketika pengguna mengklik tombol, mengetik teks, atau memilih item dari menu, program akan mengeksekusi tindakan tertentu yang sudah diprogramkan sebelumnya.
Penggunaan teknik ini tidak hanya terbatas pada antarmuka pengguna. Server dan aplikasi yang lebih kompleks, seperti layanan web dan sistem kontrol, juga menggunakan konsep event-driven untuk memproses data atau sinyal secara efisien. Hal ini menjadikan event-driven programming sebagai pendekatan yang sangat fleksibel dan cocok untuk berbagai jenis pengembangan perangkat lunak.
Dengan semakin berkembangnya teknologi, pemrograman berbasis event menjadi semakin relevan, terutama dalam konteks aplikasi yang membutuhkan respons cepat dan asinkron. Pendekatan ini memungkinkan developer menciptakan program yang tidak hanya fungsional, tetapi juga lebih responsif terhadap pengguna. Melalui artikel ini, kita akan menjelajahi lebih dalam konsep dasar, implementasi, dan manfaat dari teknik Pemrograman Berbasis Event-Driven, serta perbedaannya dengan teknik pemrograman lainnya.

Apa Itu Pemrograman Berbasis Event-Driven?

Event-Driven Programming adalah teknik pemrograman yang bekerja berdasarkan kejadian atau event tertentu. Sebagai contoh, ketika tombol A ditekan, program akan menambah nilai dari label 2 dengan hasil pembagian nilai label 3 dan label 4. Namun, jika tombol A ditekan dan label satu mengandung penjumlahan, maka program hanya akan menjumlahkan nilai dari label 2 dan label 3. 

Konsep pemrograman berbasis peristiwa atau even-driven ini mirip dengan pemrograman prosedural, yang memiliki masukan, proses, dan keluaran.Bedanya, Event-Driven Programming menambahkan elemen pemilihan untuk menentukan proses yang akan dijalankan. 

Paradigma ini mengatur alur program berdasarkan event atau kejadian, baik dari interaksi pengguna maupun pesan dari program lain.Menurut Berson (1992), sistem peristiwa terdiri dari objek-objek yang berkomunikasi melalui mekanisme pengiriman pesan yang dikelola oleh komponen-komponen khusus yang disebut pengendali peristiwa.Data yang disampaikan dalam komunikasi ini disebut event, yang dapat berasal dari masukan yang masih berupa peristiwa mentah atau dari hasil interaksi antara objek. Objek-objek ini dapat menerima kejadian dalam bentuk pesan yang terdiri dari tipe dan parameter kejadian tertentu.

Komponen-komponen Pemrograman Berbasis Event-Driven

a) Event
Event atau peristiwa adalah sebuah kejadian atau aksi yang terjadi di dalam sistem. Kejadian ini dapat dipicu oleh berbagai hal, seperti klik tombol mouse, penekanan tombol keyboard, atau aktivasi timer. Event berfungsi sebagai titik awal yang memicu rangkaian reaksi dalam program berbasis event.
b) Trigger
Trigger adalah fungsi yang sesuai dengan event tertentu. Fungsinya adalah untuk memicu komponen event handler ketika sebuah event terjadi. Trigger berperan sebagai jembatan antara event yang terjadi dan aksi yang harus diambil oleh sistem.
c) Event Handler
Event Handler adalah komponen yang bertugas untuk mengeksekusi aksi tertentu saat sebuah event terjadi. Event handler berisi kode atau instruksi yang akan dijalankan sebagai respons terhadap event yang dipicu. Fungsinya dapat mencakup memperbarui antarmuka pengguna, menjalankan logika tertentu, atau memulai proses lainnya.
d) Event Loop
Event Loop adalah mekanisme yang secara terus-menerus memantau dan mencari event yang terjadi di dalam sistem berbasis event. Proses ini berjalan dalam loop yang konstan, terus memeriksa apakah ada event baru yang harus diproses. Event loop hanya akan berhenti jika ada aksi atau event yang mengakhiri proses loop tersebut. Event loop memungkinkan aplikasi untuk tetap responsif terhadap input pengguna tanpa berhenti atau terputus.
Selain komponen-komponen di atas, dalam sistem event-driven, sering juga digunakan event queue (antrian event), yang berfungsi menampung event-event yang terdeteksi oleh event loop. Event yang berada dalam antrian akan diproses satu per satu oleh event handler sesuai urutan kemunculannya, sehingga memastikan event-event direspon secara terstruktur.

Arsitektur Event-Driven: Kembalinya Solusi Lama yang Populer

Arsitektur Event-Driven sebenarnya bukanlah konsep baru. Ide ini sudah ada sejak lama, meskipun sebelumnya dikenal dengan nama yang berbeda. Namun, dengan berkembangnya arsitektur Microservices di berbagai perusahaan, konsep Event-Driven kembali mendapatkan popularitas. Sebelum kita masuk lebih dalam ke arsitektur Event-Driven, penting untuk memahami masalah yang membuat arsitektur ini menjadi solusi yang semakin diminati.

1. Dimulai dari Monolith

Sebagian besar perusahaan memulai pengembangan sistem mereka dengan arsitektur Monolith. Alasan utamanya adalah karena Monolith lebih mudah diimplementasikan dan lebih cepat dibangun untuk fase awal. Contohnya, dalam sistem ECommerce berbasis Monolith, semua fungsi seperti pemrosesan pesanan, pembayaran, pengiriman email, manajemen pelanggan, pengelolaan produk, hingga pengelolaan kategori dilakukan dalam satu aplikasi tunggal.
Misalnya, saat ada pesanan baru, seluruh proses pembuatan pesanan, pembayaran, dan pengiriman email dikelola oleh sistem Monolith tersebut. Selama sistem Monolith tidak mengalami kendala dalam skala pengembangan atau performa, tidak ada keharusan untuk beralih ke arsitektur lain. Namun, ketika sistem mulai sulit untuk dikembangkan lebih lanjut atau skalabilitas menjadi tantangan, penggunaan arsitektur Microservices dapat menjadi alternatif yang lebih baik.

2. Beralih dari Monolith ke Microservices

Ketika sistem Monolith mulai mengalami banyak kendala, langkah umum yang diambil adalah membangun ulang sistem dengan pendekatan Microservices. Berbeda dengan Monolith, arsitektur Microservices memecah sistem menjadi layanan-layanan kecil yang saling berdiri sendiri sesuai dengan domainnya. Dalam contoh ECommerce, sistem Monolith yang sebelumnya terdiri dari satu aplikasi besar akan dipecah menjadi beberapa aplikasi, seperti aplikasi pelanggan, aplikasi pesanan, aplikasi pembayaran, dan lainnya.
Untuk proses yang sama, seperti pembuatan pesanan, pendekatannya berbeda dari Monolith. Di arsitektur Microservices, setiap tugas akan ditangani oleh layanan masing-masing. Misalnya, pesanan akan dikelola oleh order-service, pembayaran oleh payment-service, dan pengiriman email oleh email-service. Ini membuat setiap layanan bertanggung jawab terhadap domainnya tanpa harus bergantung sepenuhnya pada satu sistem besar.
Namun, tantangannya adalah bagaimana mengintegrasikan berbagai layanan tersebut. Terdapat dua pendekatan utama dalam integrasi Microservices:

3. API-Driven Architecture

Pada API-Driven Architecture, komunikasi antar layanan dilakukan melalui pemanggilan API, seperti RESTful atau RPC. Komunikasi ini umumnya bersifat sinkron, di mana satu layanan menunggu respon dari layanan lainnya. Dalam kasus ECommerce, misalnya, ketika pengguna mengirim permintaan untuk memproses pesanan, order-service akan memanggil payment-service melalui API untuk membuat pembayaran. Setelah itu, order-service akan memanggil email-service untuk mengirim email konfirmasi.

3.1. Pola Orchestration

API-Driven Architecture sering disebut sebagai Orchestration Pattern. Dalam pola ini, satu layanan bertindak sebagai orkestrator yang mengatur alur kerja antar layanan. Misalnya, order-service berperan sebagai orkestrator yang mengkoordinasikan proses pemesanan. Sedangkan payment-service dan email-service hanya mengikuti instruksi dari orkestrator tersebut.
Namun, kelemahan dari Orchestration Pattern adalah ketergantungan yang tinggi terhadap satu orkestrator. Jika ada perubahan dalam alur bisnis, seperti menambahkan layanan baru risk-service untuk mengevaluasi risiko setiap pesanan, order-service harus dimodifikasi untuk memanggil layanan baru tersebut. Selain itu, setiap panggilan API menambah latensi dan memengaruhi waktu respon, membuat pola ini sulit untuk di-scale saat layanan semakin kompleks.
Ketergantungan pada layanan lain juga menjadi masalah besar. Jika salah satu layanan, seperti payment-service, mengalami kesalahan, maka seluruh orkestrator akan terdampak, membuat stabilitas sistem terganggu.

4. Mengapa Beralih ke Event-Driven?

Sebagai alternatif terhadap API-Driven, arsitektur Event-Driven menawarkan pendekatan yang lebih fleksibel. Dalam arsitektur ini, layanan tidak perlu menunggu respon satu sama lain secara sinkron. Sebaliknya, setiap layanan hanya merespon event atau peristiwa yang relevan. Ketika order-service membuat pesanan, event tersebut dapat memicu payment-service dan email-service untuk melakukan tugas mereka masing-masing, tanpa harus dikontrol oleh satu orkestrator tunggal.
Arsitektur Event-Driven juga mengurangi ketergantungan langsung antar layanan, memungkinkan setiap komponen beroperasi secara asinkron dan lebih otonom. Hal ini membuat sistem lebih responsif, lebih mudah di-scale, dan lebih tangguh terhadap kesalahan di salah satu layanan. Implementasi Event-Driven juga sering memanfaatkan message brokers atau event buses untuk mengelola komunikasi antar layanan, sehingga pengiriman event dapat diatur lebih baik.
Dengan semakin berkembangnya teknologi cloud dan Microservices, arsitektur Event-Driven semakin relevan karena menawarkan fleksibilitas dan skalabilitas yang dibutuhkan oleh sistem modern.

5. Arsitektur Event-Driven

Sebagai alternatif dalam membangun sistem Microservices selain arsitektur API-Driven, terdapat arsitektur Event-Driven. Dalam arsitektur ini, komunikasi antar layanan dilakukan melalui pengiriman pesan berbentuk event, berbeda dengan arsitektur API-Driven yang menggunakan panggilan API. Bagaimana cara kerjanya?
Misalnya, ketika order-service menerima permintaan dari pengguna untuk membuat pesanan, order-service akan menyimpan informasi pesanan tersebut dalam database dan kemudian mengirimkan pesan event notification ke message broker seperti Kafka atau RabbitMQ.
Layanan lain yang memerlukan data pesanan tersebut, seperti payment-service, dapat mengambilnya langsung dari message broker dan menggunakannya untuk membuat data pembayaran. Demikian pula, email-service akan mengirimkan email kepada pelanggan setelah menerima data pesanan melalui message broker.

5.1 Pola Choreography

Arsitektur Event-Driven sering disebut sebagai Choreography Pattern, yang berlawanan dengan Orchestration Pattern. Pada Choreography Pattern, setiap sistem harus mengetahui tugas yang harus dilakukan saat suatu peristiwa terjadi. Ini berarti, setiap layanan bertindak sesuai dengan domainnya tanpa adanya satu layanan yang menjadi orkestrator yang menginstruksikan layanan lainnya.
Keuntungan dari menggunakan Choreography Pattern adalah, jika suatu layanan baru, seperti risk-service, memerlukan data pesanan, order-service tidak perlu mengubah kode atau melakukan panggilan API tambahan. Risk-service cukup perlu mengambil data pesanan dari message broker.
Pendekatan ini lebih mudah untuk di-scale karena tidak ada perubahan kode di order-service dan tidak ada beban tambahan pada waktu respon order-service meskipun banyak layanan yang membutuhkan data pesanan.

Bagaimana cara layanan lain mengakses data yang diperlukan?

Dalam arsitektur Event-Driven, biasanya setiap layanan yang menerima data dari message broker akan melakukan panggilan API ke layanan pengirim untuk mengambil detail data lebih lanjut. Misalnya, payment-service, email-service, dan risk-service perlu melakukan panggilan API ke order-service untuk mendapatkan data pesanan secara lengkap.
Namun, hal ini dapat menyebabkan beban pada order-service karena setiap pesan yang dikirimkan ke message broker akan diikuti dengan beberapa panggilan API ke order-service. Semakin banyak layanan yang memerlukan data pesanan, semakin banyak pula panggilan API yang harus ditangani oleh order-service.
Sekarang, order-service tidak lagi tergantung pada layanan lain, namun justru layanan seperti payment-service, risk-service, dan email-service yang bergantung pada order-service. Lalu, bagaimana cara mengatasi masalah ini?

5.2 Event-Carried State Transfer

Salah satu solusi untuk masalah yang muncul dalam arsitektur Event-Driven adalah menggunakan Event-Carried State Transfer. Intinya, Event-Carried State Transfer membuat pesan event yang dikirim oleh layanan berisi seluruh informasi yang dibutuhkan. Dalam kasus ini, pesan event yang dikirim oleh order-service akan mencakup seluruh data pesanan beserta detailnya, seperti produk yang dipesan, alamat pengiriman, alamat tagihan, dan informasi pelanggan.
Dengan Event-Carried State Transfer, setiap layanan yang mengambil data dari message broker akan menyimpan data tersebut. Meskipun terdengar kurang ideal, hal ini tidak masalah karena hanya data yang relevan yang akan disimpan. Misalnya, payment-service hanya perlu menyimpan nomor pesanan dan total harga, risk-service mungkin hanya perlu nomor pesanan, total harga, alamat pengiriman, dan identitas pelanggan, sementara email-service mungkin hanya menyimpan nomor pesanan untuk mengetahui apakah email sudah pernah dikirim.
Dengan pendekatan ini, tidak perlu ada lagi panggilan API ke layanan yang mengirim data, sehingga masalah banyaknya panggilan API yang membebani layanan pengirim tidak akan terjadi lagi. Selain itu, tidak ada layanan yang saling tergantung, menjadikan sistem lebih fleksibel.

5.3. Keuntungan Menggunakan Event-Carried State Transfer

Seperti yang sudah dijelaskan sebelumnya, penggunaan Event-Carried State Transfer menawarkan beberapa keuntungan, di antaranya:

• Tidak ada ketergantungan: Setiap layanan tidak lagi bergantung pada layanan lainnya. Ini menghilangkan kebutuhan untuk saling menunggu antar tim saat pengembangan dan mengurangi dampak kerusakan satu layanan terhadap layanan lainnya.
• High Availability: Karena setiap layanan berdiri sendiri tanpa ketergantungan, jika ada layanan yang mengalami masalah atau berhenti, layanan lain tetap berjalan tanpa terganggu.
• Mengurangi traffic ke pengirim pesan event: Tidak perlu lagi ada panggilan API ke layanan pengirim pesan event, yang mengurangi beban pada pengirim.
• Mengurangi waktu respon: Karena tidak ada lagi panggilan API ke layanan lain, waktu respon layanan menjadi lebih cepat.

5.4. Kerugian Menggunakan Event-Carried State Transfer

Namun, selain keuntungan, ada beberapa kerugian yang perlu diperhatikan saat menggunakan Event-Carried State Transfer atau arsitektur Event-Driven secara umum, seperti:

• Duplikasi data: Data dari layanan pengirim diduplikasi pada layanan penerima, yang dapat menyebabkan pembengkakan ukuran penyimpanan.
• Konsistensi yang tertunda: Event-Driven kadang tidak secepat komunikasi menggunakan API-Call, yang dapat menyebabkan penundaan dalam pengiriman dan penerimaan data, sehingga menimbulkan ketidakkonsistenan data, meskipun hanya dalam hitungan detik.
• Alur bisnis yang tersebar: Dalam arsitektur Event-Driven, alur bisnis tidak lagi terpusat pada satu layanan (seperti order-service pada API-Driven). Semua alur bisnis terdistribusi di berbagai layanan, yang membuatnya sulit bagi anggota tim baru untuk memahami gambaran besar alur bisnis tersebut.

• Tantangan di Event-Driven Architecture

Mengadopsi arsitektur Event-Driven sangat bergantung pada kondisi sistem yang ada. Jika sistem sudah besar dan membutuhkan skalabilitas serta pengembangan lebih lanjut, Event-Driven bisa menjadi pilihan tepat. Namun, untuk tahap pengembangan awal, lebih baik menggunakan Monolith, API-Driven, atau kombinasi keduanya. Migrasi sepenuhnya ke Event-Driven menghadirkan berbagai tantangan yang harus dihadapi.

Asynchronous

Event-Driven mengharuskan komunikasi antar sistem secara asinkron, berbeda dengan komunikasi sinkron yang biasa digunakan dalam API call langsung. Peralihan dari komunikasi sinkron ke asinkron ini membutuhkan perubahan paradigma yang cukup besar.

Message Schema

Di perusahaan yang sudah mengimplementasikan Microservices, setiap tim mungkin memilih teknologi yang mereka inginkan, yang berdampak pada skema pesan yang digunakan dalam arsitektur Event-Driven. Misalnya, di Blibli.com, JSON digunakan sebagai format pesan event. Perlu kesepakatan antar tim agar semua dapat menerima pesan event dengan mudah tanpa banyak perubahan kode.

Versioning

Memastikan konsistensi pesan antar versi sangat penting dalam Event-Driven. Jika format pesan baru diterapkan, perubahan drastis pada format bisa mengganggu penerima yang masih menggunakan format lama. Oleh karena itu, setiap pembaruan versi harus menjaga kompatibilitas dengan format pesan sebelumnya.

Tracing

Melakukan tracing pada arsitektur Event-Driven bisa lebih sulit, seperti yang dibahas dalam artikel sebelumnya tentang Distributed Tracing di Blibli.com. Pada arsitektur Microservices, terutama yang menggunakan Event-Driven, tracing setiap permintaan dari satu layanan ke layanan lainnya menjadi lebih rumit.

Message Order

Urutan pesan peristiwa yang didorong oleh peristiwa harus sesuai dengan pesan yang diterima oleh layanan, atau kesalahan fatal dapat terjadi. Misalnya, jika perubahan harga diterima dalam pesanan yang salah, harga yang salah dapat diterapkan.

Consumer Complexity

Event-Driven membuat layanan penerima data menjadi lebih kompleks dibandingkan API-Driven. Seperti yang dijelaskan sebelumnya, alur bisnis tersebar di seluruh layanan, tidak terpusat pada satu layanan orkestrator.

Message Broker

Arsitektur Event-Driven membutuhkan message broker yang andal sebagai penghubung antar layanan. Pastikan message broker yang digunakan stabil, skalabel, dan sesuai dengan kebutuhan sistem.

Jenis Arsitektur Event-Driven

Arsitektur Event-Driven hadir dalam beberapa variasi, masing-masing sesuai untuk aplikasi dan kebutuhan yang berbeda. Berikut beberapa jenis umum beserta contohnya dalam dunia nyata:

Complex Event Processing (CEP)

Complex Event Processing (CEP) menganalisis beberapa peristiwa untuk mengidentifikasi pola, kombinasi, dan hubungan antar peristiwa. Sistem CEP menangani volume besar peristiwa secara real-time, mengolahnya untuk wawasan yang bermakna, dan memicu tindakan berdasarkan pola peristiwa yang kompleks. Contohnya, aplikasi perdagangan keuangan dapat mendeteksi perubahan harga dari berbagai aliran peristiwa dan secara otomatis melakukan perdagangan berdasarkan aturan yang telah ditetapkan.

Arsitektur Message Queue

Dalam konfigurasi ini, antrian pesan digunakan untuk mengelola komunikasi antar komponen sistem. Produsen mengirimkan pesan ke dalam antrian, dan konsumen memprosesnya secara asinkron. Contoh umum adalah sistem e-commerce yang mengantre pesanan, sementara layanan terpisah memprosesnya. Ini membantu menyeimbangkan beban kerja dan memungkinkan front-end situs web untuk berkembang secara mandiri.

Layanan Messaging Pub/Sub (Publish/Subscribe)

Dalam model Pub/Sub, produsen mengirimkan peristiwa ke message broker, yang kemudian mendistribusikannya kepada para pelanggan untuk diproses secara asinkron. Misalnya, platform e-commerce yang menggunakan Google Cloud Pub/Sub: sebuah peristiwa "pesanan dibuat" akan memicu microservices untuk inventaris, penagihan, dan notifikasi, yang menangani pembaruan stok, pembayaran, dan konfirmasi. Ini mendukung distribusi peristiwa satu-ke-banyak, di mana beberapa konsumen menerima peristiwa yang sama.

Event Sourcing

Pola Event Sourcing mencatat perubahan status sebagai rangkaian peristiwa yang tidak dapat diubah, bukan menyimpan status saat ini secara langsung. Dengan cara ini, sistem mencatat setiap perubahan dan dapat membangun kembali status saat ini dengan memutar ulang peristiwa. Ini adalah pendekatan umum pada aplikasi perbankan yang mencatat setiap transaksi sebagai peristiwa untuk menghitung saldo saat ini.

Event Stores

Database khusus ini, yang dirancang untuk menyimpan dan mengambil data peristiwa, adalah tulang punggung dari arsitektur event-sourcing. Event store sering digunakan dalam aplikasi keuangan di mana jejak audit penting untuk riwayat transaksi, deteksi penipuan, dan pernyataan akun yang terperinci.
Memahami kekuatan dan penggunaan masing-masing model dapat membantu memilih arsitektur yang tepat untuk program berbasis event-driven Anda.

Beberapa Kelebihan Pemrograman Berbasis Event

1. Cocok untuk GUI
   Pemrograman berbasis event sering diterapkan dalam pembuatan aplikasi GUI, di mana interaksi pengguna berdasarkan kejadian tertentu, seperti klik mouse atau memilih opsi pada menu.
   
    
2. Kemudahan dalam Pemrograman
   Pemrograman berbasis event berfokus pada Event Handlers, membuat pengembangan aplikasi yang responsif lebih sederhana dan efektif dalam menangani proses dinamis.
   
    
3. Mudah Dikembangkan
   Dengan memecah aplikasi menjadi handler per peristiwa, penulisan kode menjadi lebih mudah dan mendukung pembuatan aplikasi yang bisa digunakan kembali untuk berbagai keperluan.
   
    
4. Berbasis Layanan (Service-Oriented)
   Aplikasi berbasis event sering terdiri dari beberapa layanan yang saling terintegrasi, membentuk aplikasi yang lebih kompleks.
   
    
5. Berdasarkan Waktu (Time-Driven)
   Aplikasi berbasis event berjalan dengan pengaturan waktu atau timer, bukan hanya berdasarkan instruksi langsung, memungkinkan pengelolaan tugas yang terjadwal.
   
    
6. Mudah Dimodifikasi
   Aplikasi yang dibangun dengan pendekatan event-driven cenderung fleksibel dan mudah diubah sesuai dengan kebutuhan baru.

Kesimpulan

Pemrograman berbasis event (Event-Driven Programming) telah menjadi teknik penting dalam dunia pengembangan aplikasi modern. Pendekatan ini memfokuskan pada respon terhadap kejadian atau event, seperti interaksi pengguna atau sinyal sistem, yang membuat aplikasi lebih interaktif dan responsif. Dibandingkan dengan pemrograman tradisional yang prosedural, pemrograman berbasis event memungkinkan program bereaksi secara real-time tanpa menunggu proses selesai, menjadikannya ideal untuk aplikasi desktop, web, dan mobile yang dinamis.
Teknik ini tidak hanya bermanfaat untuk antarmuka pengguna; server dan aplikasi kompleks seperti layanan web juga menggunakan event-driven untuk efisiensi. Event-driven programming terdiri dari beberapa komponen inti: event, trigger, event handler, dan event loop. Kombinasi ini memastikan aplikasi bisa merespons berbagai peristiwa secara cepat dan terstruktur.
Dalam pengembangan sistem, arsitektur Event-Driven juga semakin populer, terutama di dunia Microservices. Berbeda dengan pendekatan API-Driven yang sinkron dan terpusat pada orkestrasi, arsitektur Event-Driven memungkinkan layanan saling berkomunikasi secara asinkron melalui event. Ini meningkatkan fleksibilitas, skalabilitas, dan ketahanan sistem, mengurangi ketergantungan antar komponen.
Event-Driven Architecture, dengan konsep seperti Choreography Pattern dan Event-Carried State Transfer, meminimalkan beban komunikasi dan membuat setiap layanan dapat beroperasi secara mandiri. Dengan teknologi yang terus berkembang, pendekatan ini memberikan solusi yang efisien untuk tantangan pengembangan aplikasi modern yang memerlukan respons cepat dan asinkron. Pemrograman berbasis event bukan hanya teknik lama yang populer kembali, tetapi juga masa depan bagi pengembangan sistem yang lebih tangguh dan responsif.