Event Based

Architecture
Arjun Aksan -
05111740000133
Budiman Akbar R -
05111740000179
Event-based architecture adalah jenis arsitektur perangkat lunak yang mengembangkan produksi,
deteksi, konsumsi, dan reaksi terhadap peristiwa/event.

Suatu peristiwa dapat didefinisikan sebagai "perubahan signifikan dalam kondisi". Misalnya, ketika
konsumen membeli mobil, keadaan mobil berubah dari "dijual" menjadi "terjual".

Arsitektur sistem dealer mobil dapat memperlakukan perubahan keadaan ini sebagai peristiwa yang
kejadiannya dapat diketahui oleh fitur lain dalam arsitektur.
Studi Kasus
Misal pada kasus pembuatan pesanan, saat order-service menerima request dari pengguna, order-service akan menyimpan data
pesanan tersebut di database-nya, selanjutnya order-service akan mengirim pesan berupa event notification. Biasanya event
notification dikirim ke message broker, seperti Kafka atau RabbitMQ misalnya.

Siapapun yang membutuhkan data pesanan tersebut, maka service tersebut harus mengambil data tersebut dari message broker.
Pada kasus kita, payment-service akan menerima data pesanan dari message broker, dan secara otomatis membuat data
pembayaran untuk pesanan tersebut. Begitupula dengan email-service ketika menerima data pesanan dari message broker, maka
email-service akan mengirimkan email ke pelanggan.
 Choreography Pattern

Arsitektur Event-Driven biasa kita sebut juga dengan Choreography Pattern, ini kebalikan dari
Orchestration Pattern, dimana di Choreography Pattern, semua sistem harus mengetahui apa yang
harus dia kerjakan ketika ada sesuatu terjadi. Dalam artian, pada Choreography Pattern, semua
service harus pintar bertindak sesuai domain-nya, tidak ada lagi service yang bertugas sebagai
orkestrator yang menyuruh service lain untuk melakukan sesuatu.
Salah satu keuntungan menggunakan Choreography Pattern
adalah, misal pada kasus jika ada service baru yaitu
risk-service membutuhkan data pesanan, maka order-service
tidak perlu melakukan API call lagi, bahkan tidak perlu
melakukan apa-apa lagi. Risk-service hanya perlu mengambil
data pesanan tersebut dari message broker.

Dengan ini, secara pengembangan akan lebih scale, karena

tidak perlu ada perubahan kode di order-service, bahkan waktu
response pada order-service pun tidak akan ikut terbebani
dengan banyaknya service yang mengambil data pesanan.

Sekarang pertanyaannya, bagaimana mekanisme cara service

lain mengambil data yang dibutuhkan? Misal pada kasus ini,
bagaimana payment-service, email-service dan risk-service
mendapatkan seluruh data pesanan?
Hal yang biasa dilakukan pada arsitektur Event-Driven adalah,
service yang menerima data akan melakukan API call untuk
mendapatkan detail data tersebut ke service yang mengirim
message event tersebut. Pada kasus ini, payment-service,
risk-service dan email-service akan melakukan API call ke
order-service.

Artinya, setiap ada pesan yang dikirim ke message broker,

order-service akan di bombardir dengan API call dari semua
service. Satu request yang diterima dari pelanggan ke
order-service akan menyebabkan tiga API call ke order-service.
Semakin banyak service yang menginginkan data pesanan,
semakin banyak yang akan melakukan API call ke
order-service.

Jika diperhatikan, sekarang order-service sudah tidak

ketergantungan lagi dengan service lain. Namun justru
payment-service, risk-service dan email-service sekarang
menjadi tergantung dengan order-service. Lantas bagaimana
kita menyelesaikan permasalahan ini?
 Event-Carried State Transfer

Solusi yang dapat kita lakukan untuk permasalahan pada arsitektur Event-Driven diatas adalah,
dengan menggunakan Event-Carried State Transfer.

Sederhananya, Event-Carried State Transfer adalah menjadikan message event yang dikirim oleh
service berisikan pesan penuh. Pada kasus kita, berarti isi event yang dikirim oleh order-service
berisikan semua data pesanan plus detail pesanannya, seperti barang yang dipesan, alamat
pengiriman, alamat tagihan dan identitas pelanggan yang melakukan pemesanan.
Event-Carried State Transfer akan memaksa service yang mengambil data dari message broker untuk menyimpan data tersebut.
Hmmm, sedikit terkesan buruk, tapi tidak sepenuhnya buruk, karena yang disimpan hanyalah data yang memang dibutuhkan saja,
misal

Payment-service hanya butuh menyimpan data nomor pesanan dan total harga. Risk-service hanya butuh menyimpan no pesanan,
total harga, identitas pelanggan dan alamat pengiriman. Email-service bahkan mungkin hanya butuh menyimpan data no pesanan,
hanya untuk penanda apakah sudah pernah mengirim email atau belum.

Dengan Event-Carried State Transfer, tidak perlu lagi ada API call ke service yang mengirim data, dengan begitu permasalahan
bombardir API call dari service yang membutuhkan data tidak terjadi lagi. Begitu juga tidak ada lagi service yang tergantung dengan
service lainnya.
Keuntungan Menggunakan Event-Carried
State Transfer
Seperti yang telah dijelaskan diatas, dengan menggunakan Event-Carried State Transfer, kita mendapatkan beberapa keuntungan,
diantaranya :

❖ Tidak ketergantungan, tiap service tidak akan tergantung dengan service yang lain lagi. Tak ada lagi saling tunggu
antar team saat development, tidak ada lagi satu service bermasalah gara-gara service lainnya bermasalah.
❖ High Availability, dikarenakan tiap service sekarang berdiri sendiri tanpa ketergantungan dengan service lain, maka
secara otomatis jika ada service yang bermasalah atau mati, service lain tidak akan ikut bermasalah atau mati.
❖ Menurunkan traffic ke si pengirim pesan event, karena tidak perlu lagi ada API call ke service yang mengirimkan
pesan event.
❖ Menurunkan waktu response, karena tidak perlu melakukan API call ke service lain, sehingga membuat waktu
response service lebih bagus.
Kerugian Menggunakan Event-Carried State
Transfer
Ada keuntungan, pasti juga ada kerugian saat kita menggunakan Event-Carried State Transfer, atau bahkan menggunakan
arsitektur Event-Driven pada umumnya, diantaranya :

❖ Duplikasi data, karena data service pengirim di duplikasi di service yang menerima, maka menyebabkan media
penyimpanan menjadi lebih besar.
❖ Eventual consistent. Event-Driven kadang tidak se-realtime menggunakan API-Call, akan ada kemungkinan terjadi delay
saat service mengirim data dan menerima data, sehingga kemungkinan data tidak konsisten bisa terjadi, walaupun
mungkin hanya dalam hitungan detik.
❖ Alur bisnis yang berceceran. Pada kasus kita, jika menggunakan API-Driven untuk melihat alur bisnis, kita hanya perlu
melihatnya di order-service saja. Namun saat menggunakan Event-Driven, kita tidak bisa melihat alur bisnis secara jelas
lagi, karena semua alur bisnis sudah didistribusikan di semua service. Hal ini akan sulit bagi anggota tim baru untuk
melihat alus bisnis secara gambaran besar nya.
Hal-Hal Penting yg Harus Diperhatikan
Menggunakan arsitektur Event-Based sangat bergantung pada kondisi sistem kita
sekarang. Jika memang traffic sistem sudah besar, butuh scale secara sistem dan
pengembangan, maka ada baiknya kita menggunakan arsitektur Event-Based.

Namun jika masih pada tahap awal pengembangan, ada baiknya tetap menggunakan
Monolith, atau API-Driven, atau gabungan antara API-Driven dan Event-Based.
Karena saat kita akan melakukan migrasi secara total ke Event-Based, akan ada
banyak tantangan yang harus kita hadapi yaitu:
[ Asynchronous ]

Event-Driven menuntut kita untuk melakukan komunikasi antar sistem secara Asynchronous. Tidak ada lagi
komunikasi yang realtime mendapatkan data secara langsung dengan API call. Butuh paradigma berbeda jika
terbiasa menggunakan komunikasi synchronous lalu pindah menggunakan Event-Based sehingga
membutuhkan komunikasi asynchronous.

[ Message Schema ]

Kadang di sebuah perusahaan yang sudah menggunakan arsitektur Microservices, tiap tim bisa menentukan
teknologi yang diinginkan. Hal ini berimbas pada skema pesan yang mau digunakan dalam arsitektur
Event-Based.

[ Versioning ]

Menjaga agar pesan pada Event-Driven tetap konsisten antar versi sangatlah penting. Perlu dipastikan
bahwa jika ada versi pesan yang baru, format nya tidak akan menghancurkan format pesan sebelumnya.
Karena saat format pesan berubah secara drastis, maka penerima pesan yang masih menggunakan format
versi sebelumnya, akan bermasalah. Sehingga perlu dipastikan, tiap naik versi, format pesan tidak boleh
menghancurkan format pesan sebelumnya.
[ Tracing ]

Intinya akan lebih sulit untuk melakukan tracing tiap request dari satu service ke service yang lain pada
arsitektur Microservices, terutama yang menggunakan Event-Driven.

[ Message Order ]

Urutan pesan event pada arsitektur Event-Driven haruslah konsisten dengan yang diterima oleh service. Jika
urutan pesan tidak konsisten, maka bisa berakibat fatal. Anggap saja misal kita melakukan perubahan harga
barang sebanyak 3 kali, 1000, 2000, dan 3000. Jika urutan pesan yang diterima oleh service lain tidak
konsisten, bisa jadi harga yang seharusnya 3000, malah jadi 1000 atau 2000 karena kesalahan urutan yang
tidak konsisten pada event yang diterima.

[ Consumer Complexity ]

Event-Driven akan membuat service penerima data lebih kompleks dibandingkan jika menggunakan
API-Driven. Seperti yang dibahas sebelumnya, hal ini karena alur bisnis didistribusikan di semua service. Jadi
tidak terpusat di satu service orkestrator.
Contoh Aplikasi Berbasis Event-Based
Thank You !
Referensi:

https://en.wikipedia.org/wiki/Event-driven_architecture

K. Mani Chandy Event-Driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006

https://medium.com/bliblidotcom-techblog/event-driven-architecture-ef3a312180ee