Apa itu arsitektur berbasis peristiwa?

Hal ini memungkinkan tim untuk mengidentifikasi peristiwa sistem (pada dasarnya setiap perubahan atau tindakan yang terjadi di dalam sistem) dan merespons serta bereaksi terhadapnya secara real-time (atau nyaris seketika).

Banyaknya EDA di seluruh lingkungan cloud native menunjukkan pergeseran signifikan dari arsitektur komputasi tradisional—yang berfokus pada penimbunan data statis dalam repositori seperti data lake (seperti dalam arsitektur berorientasi layanan)—menuju pendekatan dinamis yang melacak data saat melintasi arsitektur. Data masih berharga dalam sistem berbasis peristiwa, tetapi EDA menekankan reaksi tepat waktu terhadap peristiwa, mengakui bahwa nilai suatu peristiwa mungkin berkurang seiring berjalannya waktu.

Dalam arsitektur berbasis peristiwa, produsen peristiwa (seperti layanan mikro, API, dan perangkat IoT) mengirim event notifications secara real-time ke konsumen peristiwa yang kemudian mengaktifkan rutinitas pemrosesan tertentu. Misalnya, ketika Netflix merilis serial orisinal baru, beberapa layanan EDA menunggu dalam keadaan siaga untuk pemberitahuan rilis, yang memicu serangkaian pembaruan untuk memberi tahu pengguna.

Salah satu keuntungan utama dari arsitektur berbasis peristiwa adalah hubungan terpisah antara komponen front-end dan back-end, yang memungkinkan sistem untuk berbagi informasi tanpa mengetahui satu sama lain. Produsen dapat mengirim peristiwa tanpa mengetahui konsumen mana yang akan menerimanya, dan konsumen dapat menerima peristiwa tanpa mengirim permintaan kepada produsen. Dengan kata lain, EDA memungkinkan sistem untuk bekerja secara independen dan memproses peristiwa secara asinkron.

Perusahaan modern yang berpikiran maju memiliki jejak digital yang luas, dan fungsionalitas real-time dari sistem berbasis peristiwa memungkinkan bisnis untuk mempertahankan kesiapan operasional tanpa menganggur dan merespons siaran peristiwa dengan cepat. Dengan demikian, EDA membantu perusahaan mengotomatiskan berbagai proses organisasi, mulai dari mengoptimalkan rantai pasokan hingga mengidentifikasi masalah kualitas secara proaktif, dan pada akhirnya meningkatkan pendapatan total dan keuntungan bersih mereka.

Streaming peristiwa berkisar pada aliran catatan data yang tidak terbatas, berurutan, dan real-time yang disebut "peristiwa," struktur data dasar yang mencatat setiap kejadian atau perubahan dalam sistem atau lingkungan. Contoh perubahan tersebut termasuk pengguna yang menambahkan item ke keranjang belanja mereka di situs e-commerce atau meminta untuk mengatur ulang kata sandi atau perubahan status aplikasi. Ini adalah istilah yang pada dasarnya mengacu pada setiap titik data dalam sistem. Dan “stream” (juga disebut stream data atau data streaming) adalah pengiriman berkelanjutan dari peristiwa tersebut.

Setiap peristiwa biasanya terdiri atas kunci yang mengidentifikasi peristiwa atau entitas yang terkait, nilai yang menyimpan data aktual peristiwa, stempel waktu yang menunjukkan kapan peristiwa terjadi atau direkam, dan terkadang metadata tentang sumber data, versi skema, atau atribut lainnya. Mereka dapat membawa data status (misalnya, barang yang dibeli, harga, dan alamat pengiriman) atau berfungsi sebagai pengenal (pemberitahuan pengiriman).

Dengan bantuan mesin pengolah stream khusus, peristiwa dapat mengalami beberapa proses berbeda dalam stream. “Agregasi” melakukan perhitungan data, seperti rata-rata, jumlah, dan standar deviasi. “Ingestion” menambahkan data streaming ke database. Pemrosesan analisis menggunakan pola dalam streaming data untuk memprediksi kejadian di masa depan, dan pemrosesan pengayaan menggabungkan titik data dengan sumber data lain untuk memberikan konteks dan menciptakan makna.

Peristiwa sering kali terkait dengan operasi bisnis atau proses navigasi pengguna dan biasanya memicu tindakan, proses, atau rangkaian peristiwa lain. Ambil perbankan online, sebagai salah satu contoh. Ketika pengguna mengklik "transfer" untuk mengirim uang dari satu rekening bank ke rekening bank lain, dana ditarik dari rekening pengirim dan ditambahkan ke rekening bank penerima, pemberitahuan email atau SMS dikirim ke salah satu (atau kedua) pihak, dan jika perlu, protokol keamanan dan pencegahan penipuan diterapkan.

Selain peristiwa, EDA mengandalkan tiga komponen utama untuk memindahkan data peristiwa melalui arsitektur.

• Produser peristiwa (atau penerbit): Produser adalah sumber peristiwa; mereka menghasilkan peristiwa dan mengirimkannya ke seluruh sistem. Produsen dapat berupa antarmuka pengguna, sensor, layanan, atau sistem lain yang mampu mendeteksi atau menghasilkan perubahan status yang menarik bagi bagian lain dari sistem. Meskipun produsen bertanggung jawab untuk membuat peristiwa, mereka tidak memiliki fungsi pemrosesan peristiwa.

• Konsumen (atau pelanggan) peristiwa: Konsumen menangani tugas pemrosesan peristiwa dalam EDA. Mereka mendengarkan di saluran peristiwa dan bereaksi ketika peristiwa yang menarik dipublikasikan. Reaksi ini dapat terjadi dalam berbagai bentuk, termasuk memperbarui basis data, memicu proses hilir, atau sekadar mencatat informasi.

• Pengarah peristiwa (atau pengatur peristiwa): Pengarah atau pengatur adalah perantara yang memisahkan produsen peristiwa front-end dari konsumen peristiwa backend; mereka berfungsi sebagai saluran yang dilalui peristiwa saat pengiriman, memastikan transmisi tanpa memerlukan koneksi langsung di antara entitas. Pengarah dapat didasarkan pada komponen konvensional (middleware berorientasi pesan seperti, misalnya, SaaS) dan berguna dalam berbagai sistem perpesanan (antrean pesan, model publikasi/berlangganan, event streams, dan banyak lagi).

Dalam EDA, aplikasi berbasis peristiwa bertindak sebagai produsen atau konsumen (dan terkadang keduanya).

Ketika melakukan tindakan yang mungkin ingin diketahui oleh aplikasi atau layanan lain, aplikasi atau layanan tersebut akan menerbitkan peristiwa baru, rekaman dari tindakan atau perubahan tersebut, yang dapat dikonsumsi dan diproses oleh layanan lain untuk melakukan tindakan lain.

Produser peristiwa kemudian mengirimkan peristiwa tersebut dalam bentuk pesan ke perantara atau jenis pengarah peristiwa lainnya, yang menjaga agar urutan kronologis peristiwa tersebut tetap relatif terhadap peristiwa lainnya. Konsumen peristiwa menyerap pesan—secara real time (saat terjadi) atau dalam kejadian relevan yang terjadi kemudian—dan memproses pesan tersebut untuk memicu tindakan, alur kerja, atau peristiwa lain sendiri.

Dalam contoh sederhana, layanan perbankan dapat mengirimkan peristiwa "setoran", yang akan dikonsumsi dan ditanggapi oleh layanan bank lain dengan menulis setoran ke rekening nasabah.

Namun integrasi berbasis peristiwa juga dapat memicu respons real-time berdasarkan analisis kompleks terhadap data dalam jumlah besar, seperti saat pelanggan mengklik sebuah produk di situs e-commerce dan sistem menghasilkan rekomendasi produk secara instan berdasarkan pembelian pelanggan lain.

Arsitektur berbasis peristiwa memaksimalkan potensi aplikasi cloud native dan memungkinkan teknologi aplikasi yang efektif seperti analitik real-time dan dukungan keputusan. Secara keseluruhan, mereka menggantikan arsitektur "permintaan/respons" tradisional, di mana satu aplikasi harus meminta informasi spesifik dari aplikasi lain dan menunggu balasan sebelum beralih ke tugas berikutnya.

Namun, "EDA" adalah istilah yang mencakup beberapa pola arsitektur, yang semuanya dapat berguna untuk tujuan yang berbeda:

Dalam model pub/sub, ditentukan oleh ketergantungan satu ke banyak antara objek dan hubungan asinkron yang terpisah antara penerbit (produser peristiwa) dan konsumen, penerbit tidak perlu mengetahui tentang pelanggan. Model ini hanya memublikasikan peristiwa ke saluran peristiwa bersama di mana pelanggan mendengarkan dan bereaksi terhadap peristiwa tersebut secara mandiri dan real-time.

Biasanya, perantara pesan (pengarah) menangani pengiriman pesan peristiwa antara penerbit dan pelanggan. Perantara menerima setiap pesan peristiwa, mengubahnya (jika perlu), mempertahankan agar urutannya tetap relatif terhadap pesan lain, membuatnya tersedia bagi pelanggan untuk dikonsumsi, dan kemudian menghapusnya setelah dikonsumsi (sehingga tidak dapat dikonsumsi lagi).

Pola pesan pub/sub ideal untuk bisnis dengan basis kode yang besar dan untuk menyiarkan informasi ke banyak konsumen (misalnya untuk sistem notifikasi dan umpan data real-time).

Seperti pub/sub, streaming peristiwa memisahkan penerbit dan konsumen untuk mengaktifkan komunikasi asinkron. Namun, dalam model streaming peristiwa, konsumen peristiwa tidak perlu berlangganan ke stream; sebaliknya, produsen memublikasikan stream peristiwa ke log perantara, dan konsumen dapat memasuki setiap stream kapan saja dan hanya mengonsumsi peristiwa yang ingin mereka konsumsi (alih-alih menerima dan mengonsumsi setiap peristiwa yang dipublikasikan).

Namun, tidak seperti pub/sub, perantara streaming peristiwa mempertahankan peristiwa bahkan setelah konsumen menerimanya.

Karena konsumen dapat memproses peristiwa kapan saja setelah dipublikasikan, catatan streaming peristiwa tetap ada. Ini berarti bahwa mereka dipertahankan untuk jangka waktu yang dapat dikonfigurasi (di mana saja, mulai dari sepersekian detik hingga selamanya). Konsumen dapat mengakses stream kapan saja untuk membaca pesan terbaru, melakukan pemrosesan batch serangkaian pesan dari terakhir kali mereka mengakses stream, atau mereferensikan pesan yang relevan dari masa lalu.

Teknologi streaming peristiwa (seperti Apache Kafka, Amazon Web Services (AWS) Kinesis, dan IBM® Event Automation juga mencakup dua model: model pull (di mana perantara hanya mengirim data konsumen ketika konsumen menunjukkan bahwa mereka terbuka untuk peristiwa) dan model push (di mana logika bisnis perantara menentukan konsumen mana yang menerima peristiwa).

Pola streaming peristiwa paling berguna untuk aplikasi yang membutuhkan pembaruan peristiwa real-time dan akses ke peristiwa masa lalu (misalnya sistem deteksi penipuan untuk lembaga keuangan).

Selain dua pola arsitektur EDA utama, ada tiga pola desain yang mengatur bagaimana peristiwa diproses setelah sampai ke pelanggan.

• Pemrosesan peristiwa sederhana: di mana konsumen memproses peristiwa persis seperti yang diterima dari penerbit, sehingga memicu tindakan langsung.

• Pemrosesan event streams (ESP): tempat platform streaming data menyerap peristiwa dan membangun saluran untuk mengalirkan prosesor, yang kemudian memproses dan mengubah stream tersebut.
  
  
• Pemrosesan peristiwa kompleks (CEP): di mana konsumen memproses serangkaian peristiwa untuk mengidentifikasi tren dan pola dalam data.

Ketiga pola pemrosesan (antara lain) dapat digunakan dalam pola arsitektur publikasi/berlangganan dan streaming peristiwa, tetapi ESP (secara alami) paling umum dilakukan dalam pola arsitektur streaming peristiwa.

EDA dapat berguna untuk bisnis yang beroperasi di banyak sektor, tetapi mereka sangat berharga untuk bisnis dengan lingkungan TI yang besar dan kompleks.

Perusahaan yang mencoba mengintegrasikan sistem yang berjalan di tumpukan teknologi yang berbeda, misalnya, dapat menggunakan fitur pemisahan dari arsitektur berbasis peristiwa untuk menjaga data peristiwa tetap tidak bergantung pada sistem dan meningkatkan interoperabilitas. Perusahaan multinasional dapat menggunakan EDA untuk mengoordinasikan sistem di seluruh akun dan wilayah, memfasilitasi penskalaan independen dari berbagai bagian arsitektur. Dan untuk bisnis yang menjalankan sistem yang masing-masing memproses bagian yang berbeda dari sebuah peristiwa, fitur penyebaran dari EDA dapat mendorong peristiwa ke setiap konsumen, tanpa memerlukan kode baru, untuk pemrosesan paralel di seluruh sistem.

Dalam e-commerce, arsitektur berbasis peristiwa dapat menyaring dan mengarahkan peristiwa secara real-time untuk memastikan bahwa peristiwa tersebut hanya dikirimkan ke pelanggan yang tertarik dengan data mereka. Pembelian baru langsung masuk ke konsumen yang memproses pesanan, masalah pesanan diarahkan langsung ke saluran layanan pelanggan, dan seterusnya.

Arsitektur berbasis peristiwa menjadi penting untuk menjaga bisnis masa kini tetap mengikuti perkembangan pasar dan membawa mereka ke masa depan. Faktanya, 26% organisasi berencana untuk mengadopsi EDA guna memenuhi kebutuhan bisnis, selain hampir 37% perusahaan yang sudah melakukannya.¹ Dan industri perangkat lunak EDA diperkirakan akan meningkat dua kali lipat, mencapai pendapatan lebih dari USD 16,5 miliar, pada tahun 2027.²

Ribuan peristiwa bisnis mengalir di setiap bagian organisasi setiap hari dan peristiwa ini memberikan sangat banyak informasi tentang apa yang terjadi di seluruh bisnis setiap saat. Namun, tanpa teknologi yang tepat, banyak bisnis yang tidak dapat memproses dan menggunakan data ini untuk mengambil keputusan yang tepat mengenai pelanggan, produk, atau bisnis mereka.

Di situlah platform EDA menjadi sangat berharga, memungkinkan otomatisasi proses dengan throughput tinggi dan latensi rendah, serta menyediakan alat canggih untuk berbagai contoh penggunaan, termasuk:

Arsitektur berbasis peristiwa membuat peristiwa bisnis berfungsi dengan memungkinkan pengguna untuk mendeteksi situasi yang muncul, bertindak secara real-time, mengotomatiskan pengambilan keputusan, dan memaksimalkan potensi pendapatan. EDA juga dapat membantu perusahaan mempertahankan dan mempercepat pertumbuhan, dengan memberikan:

EDA memungkinkan sistem untuk menskalakan dengan menambahkan lebih banyak contoh layanan untuk menangani peningkatan beban kerja.

EDA memungkinkan komponen untuk berkomunikasi secara asinkron; produsen memublikasikan pesan peristiwa pada jadwal mereka sendiri, tanpa menunggu konsumen menerimanya (atau bahkan mengetahui apakah konsumen menerimanya), sehingga menyederhanakan integrasi dan pengalaman pengguna.

Layanan dapat ditambahkan, dihapus, atau dimodifikasi secara independen untuk memfasilitasi praktik pengembangan dan penerapan yang tangkas.

EDA dipisahkan dalam waktu dan sinkronisasi, sehingga produsen dan konsumen peristiwa berinteraksi melalui peristiwa (bukan panggilan API langsung), yang mengurangi ketergantungan dan meningkatkan ketahanan sistem secara keseluruhan.

EDA secara inheren dirancang untuk pemrosesan dan respons real-time, sehingga tim dapat merespons secara lebih proaktif dan memfasilitasi tindakan dan otomatisasi yang lebih cerdas.