Pilih pekerjaan asinkron

Pertanyaan

Pekerjaan ini harus selesai sebelum respons dikirim, atau boleh dikerjain belakangan? Kalau belakangan, pesannya model apa: tugas, notifikasi, atau catatan kejadian?

Setelah baca ini, kamu bisa milih satu dari empat model buat sebuah alur kerja, dan nyebut apa yang kamu bayar dengan pilihan itu.

Prasyarat dan contoh

Kamu sudah kenal kontrak API dan retry yang aman (M03), transaksi (M05), dan replikasi (M08). Intinya: pesan bisa hilang, dikirim dua kali, atau datang telat.

Sebuah toko online nerima pesanan. Setelah bayar berhasil, sistem harus: kirim email struk, kurangin stok di gudang, update dashboard penjualan, dan kabarin tim fraud. Kalau semuanya dikerjain di dalam request checkout, p95 jadi 2,4 detik karena layanan email kadang butuh 1,5 detik. Kalau layanan email mati, checkout ikut gagal padahal uang sudah masuk.

Empat pekerjaan itu sebenarnya beda sifat. Email struk itu tugas: harus dikerjain sekali oleh satu worker. Dashboard dan fraud itu kabar: banyak pihak ingin tahu pesanan baru. Kalau tim analitik nanti mau ngulang hitung penjualan sebulan lalu, mereka butuh catatan kejadian yang masih ada.

Mekanisme

Request/response (sinkron). Pemanggil nunggu hasil. Cocok kalau hasilnya dipakai langsung buat respons, misalnya cek saldo sebelum nerima pembayaran. Kegagalan callee langsung jadi kegagalan pemanggil, tapi alurnya gampang dilacak.

Antrean tugas. Producer naruh pesan, satu consumer dari kelompok worker ngambil dan ngerjain, lalu pesan dihapus setelah sukses. Satu pesan, satu pemroses. Pemakaian tipikal: kirim email, resize gambar, bikin laporan PDF. Producer nggak peduli siapa yang ngerjain dan nggak dapat hasil kecuali dibikin jalur balik terpisah.

Publish/subscribe. Publisher kirim ke topik, tiap subscriber dapat salinan sendiri. Satu pesan, banyak pemroses yang nggak saling kenal. Pemakaian tipikal: "pesanan dibuat" yang didengar fraud, dashboard, dan email. Subscriber baru bisa ditambah tanpa mengubah publisher. Kalau subscriber baru gabung, biasanya dia nggak dapat pesan lama.

Event stream (log). Pesan ditulis ke log berurutan dan disimpan untuk periode retensi tertentu, misalnya 7 hari. Consumer menyimpan posisinya sendiri (offset) dan boleh baca ulang. Satu log bisa dibaca banyak kelompok consumer pada kecepatan masing-masing. Cocok buat audit, membangun ulang tampilan turunan, dan consumer yang ditambah belakangan.

Antrean:  producer → [ m3 m2 m1 ] → worker      (m1 dihapus setelah selesai)
Pub/sub:  publisher → topik → salinan → sub A, sub B, sub C
Stream:   producer → [ m1 m2 m3 m4 ... ] ← consumer A (offset 4), B (offset 1)

Batas antara pub/sub dan stream sering kabur di produk nyata, karena beberapa broker mendukung keduanya. Bedanya di perilaku yang kamu andalkan: apakah pesan dihapus setelah dikonsumsi, dan apakah consumer baru bisa baca masa lalu.

Cara memilih:

| Pertanyaan | Jawaban ya mengarah ke | | ----------------------------------------------------- | ---------------------- | | Hasil dibutuhkan sebelum respons? | Request/response | | Satu pekerjaan, satu pelaksana, dihapus setelah beres | Antrean tugas | | Banyak pihak independen perlu tahu | Pub/sub | | Perlu baca ulang, audit, atau consumer ditambah nanti | Event stream |

Saat rancangan ini gagal

• Asinkron buat yang butuh jawaban. Validasi stok dilempar ke antrean, tapi user sudah dikasih "pesanan berhasil". Setengah jam kemudian pesanan dibatalkan. Kalau keputusan menentukan respons, tetap sinkron.
• Antrean dipakai sebagai database. Pesan menumpuk 3 hari karena consumer mati, dan nggak ada yang sadar. Antrean itu penyangga, bukan penyimpanan jangka panjang.
• Pub/sub tanpa pemilik. Publisher nambah field dan menghapus yang lama. Dua subscriber yang nggak diketahui tim publisher mulai gagal parsing. Skema pesan itu kontrak.
• Stream untuk tugas sederhana. Tim memasang log terdistribusi hanya untuk kirim satu email per pesanan. Biaya operasi naik, manfaat replay nggak pernah dipakai.
• Pesan membawa seluruh data. Pesan 2 MB berisi snapshot pesanan. Pada 500 pesan/detik itu 1 GB/detik. Kirim ID dan versi, biar consumer ambil data yang dibutuhkan.

Contoh tandingan: "antrean lebih baik karena lebih tahan gagal". Kalau layanan email lambat tapi checkout tetap sinkron menunggunya, memang jelek. Tapi kalau pekerjaannya cuma 8 ms di dalam proses yang sama, menambah broker menambah satu komponen yang bisa mati tanpa mengurangi risiko apa pun.

Latihan

Pilih model buat tiap pekerjaan, lalu sebut satu hal yang kamu bayar.

1. Cek kode voucher sebelum menampilkan total belanja.
2. Bikin thumbnail setelah user unggah foto profil.
3. Kabari layanan rekomendasi, pencarian, dan email bahwa produk berubah harga.
4. Tim data minta bisa hitung ulang metrik 30 hari terakhir dari semua klik.

Lihat pembahasan+

1. Request/response. Hasilnya langsung menentukan angka yang ditampilkan. Harganya: latensi dan ketersediaan layanan voucher ikut menjadi milik halaman checkout. Beri timeout dan tentukan fallback.
2. Antrean tugas. Satu foto, satu pemroses, dihapus setelah thumbnail jadi. Harganya: ada jeda sebelum thumbnail muncul, jadi UI butuh gambar sementara dan status "diproses". Worker harus aman diulang (lihat M10.02).
3. Pub/sub. Tiga pihak independen, dan pihak keempat bisa ditambah tanpa mengubah publisher. Harganya: publisher nggak tahu siapa yang sudah memproses, dan skema event harus dijaga kompatibel.
4. Event stream. Perlu retensi minimal 30 hari dan consumer baru yang bisa baca dari awal. Harganya: penyimpanan, partisi, dan operasi log. Kalau 30 hari klik 2 miliar event rata-rata 300 byte, itu sekitar 600 GB sebelum replikasi.

Terkait

• M10.02 Tentukan perilaku pengiriman bahas apa yang terjadi saat pesan hilang atau dikirim dua kali.
• M10.04 Pertahankan urutan yang diperlukan melanjutkan model stream dengan partisi dan offset.
• M01.04 Pasang target yang masuk akal membantu menentukan jeda yang boleh diterima.
• M03 (retry yang aman) dan M08 (replikasi) dibahas di modul masing-masing.

Catatan

• Asumsi: broker berperilaku umum. Fitur persis berbeda antar produk, jadi cek dokumentasi produk yang kamu pakai.
• Hitungan 600 GB: 2 × 10^9 × 300 byte = 6 × 10^11 byte, tanpa replikasi dan kompresi.
• Yang nggak dibahas: pemilihan produk broker tertentu, biaya terkelola, dan jaminan urutan (lihat M10.04).
• Terakhir ditinjau: 26 Oktober 2026.