Apa itu berbasis acara, dan seberapa cepat waktu nyata?
Jika kita memikirkannya, kita dapat mengidentifikasi banyak skenario berbasis peristiwa. Banyak dari mereka membutuhkan reaksi secara real time.
Apa yang kita maksud dengan waktu nyata?
Reaksi secara real time dapat dilihat sebagai jawaban langsung. Mari kita ambil contoh kasir di kedai kopi yang bertanya apa yang ingin Anda minum.
Kasir mengharapkan jawaban instan, atau setidaknya jawaban yang diberikan segera. Jika tidak, kasir mungkin mengulangi pertanyaan atau mencurigai bahwa Anda kasar. Diminta jawaban yang cepat dan tepat. Waktu untuk menjawab dapat sedikit bervariasi, tetapi tetap dianggap "dalam waktu nyata." Jadi, membalas salam harus dilakukan dengan cepat, namun tidak masalah untuk berpikir sebentar tentang pesanan Anda sebelum menjawab pertanyaan kasir.
Jika Anda menerjemahkan skenario tersebut ke sistem perangkat lunak, yang Anda pedulikan hanyalah waktu: Waktu Respons, Waktu Penyelesaian, Waktu Akses, Waktu Mulai, dan sebagainya. Pengguna atau aplikasi yang mengakses mendefinisikan waktu tersebut.
Nota
Secara real time, tugas sistem melakukan fungsinya dalam tenggat waktu yang ditentukan.
Anda harus selalu menyadari apa yang terjadi dalam sistem Anda. Jadi pastikan Anda tidak melupakan yang jelas, yaitu pencatatan, pemantauan, dan pengukuran waktu.
Penting
Pastikan Anda menentukan tenggat waktu dan jadwal terlebih dahulu serta menyiapkan solusi pemantauan yang tidak mengganggu untuk pemeriksaan.
Singkatnya, kami setuju bahwa real time berarti super cepat, dalam sekejap. Seberapa cepat tepatnya ditentukan oleh skenario yang Anda berikan.
Aplikasi berbasis peristiwa
Jika Anda berpikir tentang peristiwa ketika Anda mengklik, Anda justru memikirkan hal yang lain. Aplikasi berbasis peristiwa menggunakan prinsip tembak dan lupakan. Peristiwa dikirim atau diaktifkan menuju sistem berikutnya, yang dapat berupa layanan lain, hub acara, alur data, atau broker pesan seperti Kafka. Kami tidak mesti menunggu respons dari yang berikutnya dalam sistem. Kopling longgar dicapai dengan mengorbankan konsistensi akhir, yang perlu ditangani pada tingkat lain.
Untuk mengidentifikasi sifat aplikasi berbasis peristiwa, mari kita lihat pola arsitektur utama dengan menggunakan contoh pelanggan, bernama Alex, membeli kopi dan cappuccino.
Pemberitahuan peristiwa
Pemberitahuan peristiwa adalah pemberitahuan kejadian atau peristiwa tertentu. Setiap peristiwa dilihat secara terpisah. Contoh pelanggan bernama Alex yang membeli kopi dan cappuccino mungkin terlihat seperti ini:
1. Acara: Alex membeli kopi.
2. Peristiwa: Alex membeli cappuccino.
Satu barista harus mendengarkan dengan cermat semua peristiwa untuk mendapatkan seluruh pesanan Alex. Tetapi dua barista juga dapat menyiapkan dan menyajikan minuman secara mandiri.
Peristiwa mengakibatkan pemindahan status
Dengan transfer status yang dilakukan melalui peristiwa, semua informasi yang diperlukan disimpan dalam satu peristiwa. Itu berguna jika suatu peristiwa tidak terdeteksi atau layanan Anda tidak merespons semua peristiwa. Misalnya, peristiwa akan terlihat seperti ini:
1. Acara: Alex membeli kopi.
2. Acara: Alex membeli, selain kopi, sebuah cappuccino.
Dengan satu barista, hanya mendengarkan peristiwa kedua mungkin cukup. Dengan dua barista, barista kedua harus melihat yang pertama. Pesanan dapat disajikan bersama, tetapi prosesnya mungkin memakan waktu lebih lama daripada melakukannya sepenuhnya terpisah.
Sumber peristiwa
Dengan pendataan peristiwa, penyimpanan peristiwa menjadi fokus. Seperti yang Anda lihat, peristiwanya sama seperti dalam contoh pertama. Namun, barista penting bagi konsep ini pada saat barista menghadapi peristiwa dan kemudian mempertimbangkan semua kejadian terkait untuk mendapatkan keadaan terkini dari semua pesanan yang dilakukan oleh Alex.
Dengan pesanan kedua, barista tahu bahwa pesanan Alex terdiri dari satu kopi, dengan mengingat pesanan pertama, dan satu cappuccino, karena minuman ini baru saja dipesan. Bekerja secara paralel dengan barista kedua tidak semudah itu.
Ketika kita menambahkan kasir untuk menerima pesanan dan menyajikan minuman, barista dapat bekerja secara mandiri untuk menyiapkan minuman. Mereka tidak perlu tahu apa-apa tentang pelanggan. Kasir adalah yang disebut sebagai penyimpanan peristiwa, yang menyimpan peristiwa, dalam skenario itu. Pemanfaatan event sourcing menambah lapisan kompleksitas, tetapi juga meningkatkan pemisahan antarkomponen.
1. Acara: Alex membeli kopi.
Kasir: (Pertama) pesanan (untuk Alex): Kopi
2. Peristiwa: Alex membeli cappuccino.
Kasir: (Kedua) pesanan (untuk Alex): Cappuccino
Data telemetri adalah peristiwa waktu nyata
Ada juga contoh lain yang dapat kita pikirkan. Bayangkan skenario menjalankan sistem pendingin, misalnya, untuk produsen makanan atau obat. Anda memerlukan kontrol konstan terhadap suhu dan data relevan lainnya dalam sistem Anda. Kesadaran akan data telemetri dan mengontrolnya secara otomatis akan sangat penting bagi kesuksesan Anda. Mengukur telemetri setiap dua detik dan kemudian mengirimkannya ke sistem kontrol tempat data dianalisis, diproses, dan ditangani adalah sistem berbasis peristiwa. Selain itu, data harus diproses secara real time karena sangat penting untuk bereaksi dengan cepat untuk menghindari konsekuensi tragis bagi bisnis.