At-most-once #

Berbeda dengan at-least-once yang memprioritaskan agar pesan tidak hilang, at-most-once berada di sisi lain spektrum delivery guarantee.

Dalam model ini:

• Setiap message dikirim maksimal satu kali
• Tidak ada retry otomatis jika gagal
• Tidak ada duplicate
• Tetapi ada kemungkinan message hilang

Artikel ini membahas bagaimana at-most-once bekerja di RabbitMQ, bagaimana ia dikonfigurasi, tradeoff-nya, dan kapan ia masuk akal digunakan.

“Jika pesan gagal diproses, sistem tidak akan mencoba lagi — dan mungkin tidak pernah ada kesempatan kedua.”

Apa Itu At-Most-Once Delivery? #

At-most-once berarti:

• Message akan diproses paling banyak satu kali
• Jika terjadi kegagalan sebelum selesai → message tidak dikirim ulang

Tidak ada duplicate.

Namun tidak ada jaminan pesan benar-benar diproses.

Model ini memprioritaskan kesederhanaan dan performa.

Bagaimana At-Most-Once Terjadi di RabbitMQ? #

At-most-once biasanya terjadi jika:

1️⃣ Menggunakan Auto-Ack (Automatic Acknowledgement) #

Saat consumer menerima message dengan auto-ack:

• Broker langsung menganggap message selesai
• Message langsung dihapus dari queue
• Bahkan sebelum benar-benar diproses

Alur:

1️⃣ Broker kirim message 2️⃣ Broker langsung tandai sebagai ack 3️⃣ Consumer memproses 4️⃣ Jika crash di langkah 3 → message hilang

2️⃣ Tidak Menggunakan Publisher Confirm #

Jika producer publish tanpa confirm:

• Tidak ada jaminan message benar-benar tersimpan
• Jika broker crash sebelum flush ke disk → message hilang

3️⃣ Menggunakan Non-Persistent Message #

Jika message tidak persistent dan broker restart:

• Message hilang

Mengapa At-Most-Once Bisa Lebih Cepat? #

Karena:

• Tidak perlu manual ack
• Tidak perlu retry
• Tidak perlu tracking unacked
• Tidak perlu confirm

Lebih sedikit koordinasi → latency lebih rendah.

Namun reliability menurun.

Risiko Utama At-Most-Once #

1️⃣ Silent Data Loss #

Jika consumer crash setelah menerima message:

• Message sudah dihapus
• Tidak ada mekanisme pengiriman ulang

2️⃣ Tidak Cocok untuk Workload Kritis #

Jika message adalah:

• Payment event
• Order processing
• Inventory update

Kehilangan satu message bisa berakibat fatal.

3️⃣ Sulit Dideteksi #

Karena tidak ada retry atau DLQ otomatis:

• Kehilangan message bisa tidak terlihat

At-most-once sering kali gagal secara diam-diam.

Kapan At-Most-Once Masuk Akal? #

Model ini masih relevan untuk beberapa kasus:

1️⃣ Telemetry atau Metrics #

Jika satu message hilang:

• Tidak kritis

2️⃣ Logging Non-Kritis #

Jika log tidak terkirim:

• Tidak memengaruhi bisnis utama

3️⃣ Cache Invalidation yang Idempotent #

Jika update cache gagal sekali:

• Akan diperbarui lagi nanti

4️⃣ Sistem dengan Toleransi Tinggi terhadap Loss #

Workload yang tidak memerlukan akurasi absolut.

Perbandingan dengan At-Least-Once #

At-most-once lebih sederhana, tetapi kurang aman.

Kesalahan Umum #

Beberapa tim tanpa sadar menggunakan at-most-once karena:

• Mengaktifkan auto-ack
• Tidak menggunakan confirm
• Tidak membuat queue durable

Padahal mereka mengira sistem sudah reliable.

Delivery guarantee sering kali terjadi karena konfigurasi, bukan niat desain.

Prinsip Menggunakan At-Most-Once dengan Sadar #

Jika memilih at-most-once:

• Pastikan workload benar-benar toleran terhadap loss
• Dokumentasikan keputusan ini
• Monitor error rate
• Jangan gunakan untuk transaksi penting

Keputusan delivery guarantee harus eksplisit.

Ringkasan #

At-most-once berarti:

• Cepat
• Sederhana
• Tidak ada duplicate
• Tetapi message bisa hilang

Ia cocok untuk workload non-kritis.

Tidak cocok untuk alur bisnis utama.

Penutup #

Dalam sistem terdistribusi, tidak ada jaminan tanpa tradeoff.

At-most-once memilih performa dan kesederhanaan.

Sebagai gantinya, ia menerima risiko kehilangan pesan.

Untuk beberapa use case, itu masuk akal.

Namun untuk sistem bisnis kritikal, kehilangan satu pesan bisa lebih mahal daripada memproses dua kali.

Karena dalam arsitektur messaging, keputusan delivery guarantee bukan soal teknis semata.

Ia adalah keputusan risiko.

Dan risiko harus dipilih dengan sadar, bukan terjadi secara tidak sengaja.