Arsitektur Event-Driven dan Antrean Pesan untuk Aplikasi Bisnis: Cepat, Tahan Lonjakan, dan Mudah Dikembangkan

Ketika pelanggan menekan tombol bayar di toko online, banyak hal harus terjadi: pesanan dicatat, stok dikurangi, faktur dibuat, email konfirmasi dikirim, gudang diberi tahu, poin loyalitas ditambah, dan data masuk ke laporan. Pada aplikasi yang dirancang sederhana, semua langkah itu dikerjakan berurutan dalam satu proses. Selama pesanan sedikit, tampaknya baik-baik saja. Begitu satu langkah melambat, misalnya server email tersendat, seluruh pesanan ikut tertahan, dan pelanggan menatap layar yang berputar sambil bertanya apakah pembayarannya berhasil.

Arsitektur berbasis kejadian (event-driven) dan antrean pesan (message queue) adalah cara merancang aplikasi agar langkah-langkah itu tidak saling menyandera. Artikel ini menjelaskan konsepnya tanpa jargon berlebihan, kapan pendekatan ini layak dipakai di aplikasi bisnis, pola yang umum, risiko yang harus dikelola, dan cara memulai secara bertahap tanpa menulis ulang seluruh sistem.

Ringkasan

• Antrean pesan memisahkan pekerjaan yang harus selesai sekarang dari pekerjaan yang boleh menyusul, sehingga pengguna tidak menunggu langkah sekunder
• Arsitektur berbasis kejadian membuat modul saling memberi tahu lewat kejadian, bukan saling memanggil secara langsung, sehingga lebih longgar terhubung
• Manfaat utama: ketahanan terhadap lonjakan beban, kegagalan yang terisolasi, dan kemudahan menambah fungsi baru
• Harga yang dibayar: kompleksitas, data yang konsistensinya tertunda, dan kebutuhan pemantauan yang lebih baik
• Mulailah dari satu alur yang jelas bermasalah, seperti notifikasi atau sinkronisasi ke sistem lain, bukan dari merombak semuanya

Masalah pada alur yang dikerjakan berurutan

Dalam desain sinkron, satu permintaan pengguna memicu rangkaian pekerjaan yang semuanya harus selesai sebelum jawaban dikirim kembali. Pola ini sederhana, tetapi menimbulkan beberapa masalah yang akrab.

• Lambat di mata pengguna: waktu tunggu adalah jumlah semua langkah, termasuk langkah yang sebenarnya tidak perlu ditunggu, seperti mengirim email
• Rapuh terhadap kegagalan: bila layanan pihak ketiga mati, seluruh proses gagal meski inti pekerjaan sudah berhasil
• Sulit menahan lonjakan: saat kampanye atau promo, ribuan permintaan menumpuk di titik terlemah dan menjatuhkan seluruh aplikasi. Topik ini berkaitan dengan [uji beban sebelum promo besar](/blog/load-testing-uji-beban-sebelum-promo-besar-dan-musim-puncak)
• Keterkaitan erat: menambah satu fungsi baru, misalnya mengirim data ke sistem analitik, berarti mengubah kode alur utama dan berisiko merusaknya
• Pengulangan yang tidak aman: bila pengguna menekan tombol dua kali karena lambat, pekerjaan bisa terduplikasi

Contoh nyata: proses checkout memanggil layanan pembayaran, lalu layanan pengiriman, lalu sistem akuntansi, lalu email. Jika sistem akuntansi sedang pemeliharaan lima menit, pelanggan yang sudah membayar mendapat pesan galat. Pembayaran sudah terjadi, tetapi pesanan tampak gagal, dan tim dukungan harus membereskannya secara manual.

Konsep dasar: antrean, kejadian, dan pekerja

Ada beberapa istilah yang cukup dipahami pada tingkat gagasan.

Antrean pesan

Antrean pesan adalah tempat penyimpanan sementara yang tertib untuk pekerjaan yang menunggu diproses. Pengirim menaruh pesan, misalnya "kirim email konfirmasi untuk pesanan 1042", lalu langsung melanjutkan tugasnya. Pekerja lain mengambil pesan itu dan mengerjakannya kapan siap. Bila pekerja sibuk atau mati sebentar, pesan menunggu dengan aman.

Kejadian

Kejadian adalah catatan fakta bahwa sesuatu telah terjadi, misalnya "pesanan dibuat", "pembayaran diterima", atau "stok menipis". Penamaan dalam bentuk lampau menegaskan bahwa kejadian tidak bisa dibantah; yang bisa dilakukan pihak lain hanyalah bereaksi terhadapnya.

Produsen dan konsumen

Produsen adalah bagian aplikasi yang mengumumkan kejadian atau menaruh pekerjaan di antrean. Konsumen adalah bagian yang mendengarkan dan bereaksi. Satu kejadian bisa didengarkan banyak konsumen sekaligus: kejadian "pesanan dibuat" dapat memicu pengurangan stok, pembuatan faktur, dan notifikasi tanpa produsen perlu tahu siapa saja mereka.

Perantara pesan

Perantara (broker) adalah komponen yang menjaga antrean dan mengatur pengiriman pesan ke konsumen. Pilihannya beragam, dari layanan terkelola di cloud hingga perangkat lunak yang dipasang sendiri. Bagi sebagian besar bisnis menengah, layanan terkelola mengurangi beban operasional dibanding mengelola sendiri.

Pola yang umum dipakai di aplikasi bisnis

Pekerjaan latar belakang

Pola paling sederhana dan paling sering bermanfaat: pekerjaan yang tidak perlu ditunggu pengguna dipindahkan ke antrean. Contohnya mengirim email dan notifikasi, membuat berkas laporan besar, mengubah ukuran gambar unggahan, dan mengimpor berkas data. Pengguna langsung mendapat jawaban "diterima" sementara proses berjalan di belakang.

Publikasi dan langganan

Satu kejadian diumumkan, banyak pihak berlangganan. Pola ini cocok untuk modul ERP yang saling bergantung. Ketika penjualan dicatat, modul stok, keuangan, dan CRM bereaksi masing-masing. Menambah konsumen baru, misalnya modul analitik, tidak mengubah produsen.

Sinkronisasi antarsistem

Menyalin perubahan data dari satu sistem ke sistem lain, seperti dari ERP ke toko online atau marketplace, sangat cocok memakai antrean. Perubahan stok dikirim sebagai kejadian, dan bila sistem tujuan sedang tidak tersedia, kejadian menunggu lalu dikirim ulang. Pola ini melengkapi webhook dan integrasi real-time dan relevan untuk menyatukan stok toko fisik dan marketplace.

Perataan lonjakan

Saat lalu lintas melonjak, permintaan ditampung di antrean dan diproses dengan kecepatan yang bisa ditanggung sistem. Pengguna mungkin menunggu sedikit lebih lama untuk hasil akhir, tetapi aplikasi tidak runtuh.

Alur kerja panjang

Proses bisnis yang melibatkan beberapa tahap dan bisa memakan waktu, seperti persetujuan berjenjang atau penyelesaian pesanan, dapat dimodelkan sebagai rangkaian kejadian dengan status yang tercatat di setiap langkah.

Risiko dan harga yang harus dibayar

Pendekatan ini bukan peluru perak. Beberapa konsekuensinya perlu dipahami sebelum memutuskan.

• Konsistensi tertunda: setelah pesanan dibuat, stok mungkin baru berkurang beberapa detik kemudian. Aplikasi harus dirancang agar tampilan tetap masuk akal selama jeda itu
• Pesan ganda: sistem antrean umumnya menjamin pesan sampai setidaknya sekali, sehingga pesan yang sama bisa terkirim dua kali. Konsumen harus aman diulang (idempoten), misalnya dengan mencatat nomor pesan yang sudah diproses
• Urutan tidak selalu terjamin: kejadian "pesanan dibatalkan" bisa tiba sebelum "pesanan dibuat" bila jalurnya berbeda. Perlu desain yang menangani urutan atau memakai nomor versi
• Pesan beracun: pesan yang selalu gagal diproses bisa menyumbat antrean. Gunakan batas percobaan ulang dan antrean khusus untuk pesan gagal agar bisa diperiksa manusia
• Sulit dilacak: satu tindakan pengguna menyebar ke banyak konsumen, sehingga tanpa pengenal korelasi dan [observabilitas yang baik](/blog/observabilitas-log-dan-penanganan-error-aplikasi-bisnis), pencarian akar masalah menjadi menyulitkan
• Biaya operasional: satu komponen tambahan perlu dipantau, diamankan, dan dicadangkan
• Kompleksitas pengujian: menguji alur asinkron lebih rumit daripada memanggil satu fungsi

Karena itu, jangan memakai antrean untuk hal yang cukup ditangani langsung. Bila sebuah operasi cepat dan harus dipastikan berhasil sebelum menjawab pengguna, seperti memvalidasi kartu atau mengurangi stok yang terbatas, pendekatan sinkron sering lebih sederhana dan lebih aman.

Menjaga data tetap benar: idempotensi dan transaksi

Dua praktik teknis menentukan apakah desain berbasis kejadian dapat dipercaya.

Idempotensi

Operasi idempoten menghasilkan hasil yang sama meskipun dijalankan berkali-kali. Misalnya, "tandai pesanan 1042 sebagai dibayar" aman diulang, sedangkan "tambah saldo 100.000" tidak. Rancang konsumen agar memeriksa apakah suatu pesan sudah pernah diproses, memakai nomor unik pesan atau nomor pesanan sebagai kunci. Prinsip yang sama berlaku untuk notifikasi dari penyedia pembayaran, sebagaimana dibahas di integrasi payment gateway.

Penyimpanan kejadian yang andal

Masalah halus muncul bila aplikasi menyimpan data ke basis data lalu mengirim pesan ke antrean sebagai dua langkah terpisah. Bila aplikasi mati di antara keduanya, data tersimpan tetapi pesan tidak terkirim, atau sebaliknya. Pola kotak keluar (outbox) mengatasinya: pesan ditulis ke tabel khusus dalam transaksi basis data yang sama dengan perubahan datanya, lalu proses terpisah mengirimkannya ke antrean. Dengan begitu, perubahan data dan pengumuman kejadian selalu berjalan bersama.

Kapan pendekatan ini layak dipakai

Tidak setiap aplikasi membutuhkannya. Beberapa tanda bahwa antrean dan kejadian akan memberi nilai:

• Ada langkah yang lambat atau tidak andal, seperti email, ekspor laporan, atau panggilan ke sistem eksternal, yang membuat pengguna menunggu
• Lonjakan beban musiman atau kampanye membuat aplikasi tersendat
• Beberapa sistem perlu mengetahui perubahan yang sama, misalnya ERP, toko online, dan analitik
• Kegagalan sistem pihak ketiga tidak boleh menggagalkan transaksi inti
• Anda berencana menambah banyak integrasi di masa depan dan ingin menghindari kode yang saling terjerat

Sebaliknya, aplikasi kecil dengan beberapa puluh pengguna dan alur sederhana biasanya lebih baik tanpa komponen tambahan. Pertimbangkan juga hubungannya dengan keputusan monolit atau microservices: antrean dapat dipakai di dalam satu aplikasi monolit yang rapi, tanpa harus memecahnya menjadi banyak layanan.

Memantau antrean

Antrean yang tidak dipantau adalah masalah yang menunggu waktu. Beberapa indikator yang layak dipasang peringatan:

• Panjang antrean: jumlah pesan yang menunggu. Kenaikan terus-menerus berarti konsumen tidak mengejar
• Umur pesan tertua: seberapa lama pesan paling lama menunggu. Ini sering lebih bermakna daripada panjang antrean
• Tingkat kegagalan dan percobaan ulang: lonjakan menandakan gangguan pada konsumen atau sistem tujuan
• Isi antrean pesan gagal: setiap pesan di sana perlu ditinjau dan diputuskan nasibnya
• Waktu proses per pesan: tren naik bisa menandakan masalah performa, termasuk di basis data seperti dibahas di [performa database dan aplikasi yang melambat](/blog/performa-database-dan-aplikasi-bisnis-yang-melambat)
• Pemakaian sumber daya pekerja: menentukan kapan perlu menambah kapasitas

Catat pengenal korelasi pada setiap pesan sehingga satu tindakan pengguna dapat dilacak dari awal sampai semua konsumen yang bereaksi.

Langkah memulai secara bertahap

• Identifikasi satu alur yang jelas menyakitkan, misalnya checkout yang lambat karena email atau sinkronisasi stok yang sering gagal
• Pindahkan hanya langkah sekunder ke antrean, dan biarkan langkah inti tetap sinkron
• Rancang pesan dengan pengenal unik, versi, dan data secukupnya, bukan seluruh objek
• Buat konsumen idempoten dan tentukan kebijakan percobaan ulang serta antrean pesan gagal
• Pasang pemantauan dan peringatan sebelum diluncurkan, bukan sesudah ada masalah
• Uji skenario kegagalan: matikan konsumen, kirim pesan ganda, dan simulasikan sistem tujuan yang lambat
• Luncurkan bertahap, misalnya dengan [feature flag dan rilis bertahap](/blog/feature-flag-dan-rilis-bertahap-untuk-aplikasi-bisnis), lalu perluas ke alur lain setelah terbukti stabil

Kesalahan yang sering terjadi

• Memakai antrean untuk segalanya, termasuk hal yang sederhana dan harus sinkron
• Tidak menangani pesan ganda sehingga pelanggan menerima dua email atau dua kali penagihan
• Membiarkan pesan gagal menumpuk tanpa ada yang memeriksa
• Mengirim objek besar dalam pesan sehingga data cepat kedaluwarsa atau tidak konsisten
• Tidak menyertakan pengenal korelasi sehingga pelacakan masalah memakan waktu berhari-hari
• Mengabaikan keamanan: pesan bisa memuat data pribadi sehingga akses dan enkripsi perlu diatur

Pertanyaan yang sering diajukan

Apakah bisnis kecil perlu antrean pesan?

Sering kali belum. Mulailah dari fitur pekerjaan latar belakang yang disediakan kerangka aplikasi Anda. Komponen perantara terpisah baru bermanfaat saat volume, jumlah sistem terhubung, atau tuntutan ketahanan meningkat.

Apa bedanya antrean dengan webhook?

Webhook adalah cara satu sistem memberi tahu sistem lain lewat panggilan HTTP saat sesuatu terjadi. Antrean adalah tempat penampungan yang menjaga pesan tetap aman bila penerima sedang tidak tersedia. Keduanya sering dipakai bersama: webhook yang masuk ditaruh di antrean dulu, baru diproses.

Apakah ini sama dengan microservices?

Tidak. Antrean dan kejadian adalah pola komunikasi yang bisa dipakai di aplikasi monolit maupun microservices. Banyak bisnis mendapat manfaat besar dari antrean tanpa memecah aplikasinya.

Bagaimana dengan keamanan data dalam pesan?

Batasi data pribadi dalam pesan, gunakan pengenal untuk merujuk data lengkap, atur hak akses ke antrean, dan aktifkan enkripsi saat transit dan penyimpanan sesuai kebutuhan. Pesan gagal yang disimpan lama juga perlu kebijakan retensi.

Berapa lama menerapkannya pada satu alur?

Untuk satu alur sederhana seperti notifikasi, hitungan hari hingga beberapa minggu, termasuk pengujian dan pemantauan. Alur yang menyangkut sinkronisasi antarsistem atau data keuangan membutuhkan waktu lebih lama karena pengujian kegagalannya lebih menuntut.

Kesimpulan

Arsitektur berbasis kejadian dan antrean pesan membantu aplikasi bisnis tetap cepat di mata pengguna, tahan terhadap lonjakan dan gangguan, serta mudah dikembangkan tanpa membongkar alur utama. Harganya adalah kompleksitas tambahan yang harus dikelola dengan idempotensi, penanganan pesan gagal, dan pemantauan yang baik. Mulailah kecil pada alur yang jelas bermasalah, ukur hasilnya, dan perluas bila terbukti bermanfaat.

Agsora membantu merancang dan membangun integrasi antarsistem yang andal, dari ERP, toko online, hingga layanan pihak ketiga, termasuk penanganan kegagalan dan pemantauannya. Bila aplikasi Anda sering tersendat saat ramai atau sinkronisasi antarsistem tidak dapat diandalkan, mari kita bahas solusinya.