Poison Message Handling #

Dalam sistem antrean pesan terdistribusi (distributed message queuing), tidak semua data yang masuk ke antrean dapat diproses hingga selesai. Adakalanya kita menemui jenis pesan tertentu yang selalu memicu kegagalan pemrosesan setiap kali dicoba oleh konsumen (consumer). Kegagalan ini tidak bersifat sementara (transient), melainkan permanen akibat cacat bawaan pada payload pesan itu sendiri atau karena adanya bug logika pada kode aplikasi konsumen kita. Jenis pesan bermasalah seperti ini dikenal secara industri sebagai Poison Message (pesan racun).

Bahaya utama dari poison message bukanlah kegagalannya itu sendiri, melainkan dampak berantai yang dipicunya jika sistem kita tidak memiliki proteksi penanganan yang tepat. Tanpa adanya pembatasan retry, broker RabbitMQ akan terus-menerus mengirimkan kembali (redelivering) pesan rusak tersebut ke konsumen secara instan. Konsumen akan terjebak dalam siklus tanpa akhir: menerima pesan, crash/gagal, melakukan requeue, dan langsung menerima pesan yang sama lagi. Siklus mematikan ini dapat melumpuhkan performa CPU sistem, memenuhi penyimpanan disk dengan log error yang berulang, dan memblokir jutaan pesan sehat lainnya di dalam antrean dari kesempatan untuk diproses.

Mengapa Poison Message Terjadi? #

Poison message biasanya lahir dari ketidaksesuaian kontrak data antara produsen (producer) dan konsumen (consumer), atau karena adanya kasus ekstrem (edge cases) yang belum ditangani oleh kode aplikasi kita. Beberapa pemicu paling umum terjadinya poison message di lingkungan produksi meliputi:

  1. Format Data Cacat (Malformed Payload): Produsen mengalami bug yang menyebabkan ia mengirimkan data kosong, format string yang tidak lengkap, atau payload biner yang rusak yang tidak dapat diuraikan (parsing) oleh konsumen.
  2. Ketidakcocokan Skema (Schema Mismatch): Tim produsen merilis versi aplikasi baru yang mengubah struktur skema JSON (misalnya mengubah tipe data field user_id dari integer menjadi UUID string), sementara tim konsumen belum memperbarui kode mereka untuk mengenali tipe data baru tersebut.
  3. Pelanggaran Constraint Database Permanen: Payload pesan berisi data duplikat yang melanggar kunci unik (unique key constraint) pada database konsumen, atau mereferensikan ID entitas eksternal yang tidak pernah ada di database tujuan.
  4. Bug Logika Aplikasi (Catch-All Panic): Pesan berisi nilai tertentu yang memicu kondisi null pointer exception atau out-of-bounds array access di dalam kode konsumen yang tidak diantisipasi dengan penanganan error (recovery context).
flowchart TD
    Producer["Produsen Mengirimkan Payload Rusak"] --> Queue["Exchange & Antrean"]
    Queue --> ConsumerA["Konsumen A Menerima & Parsing"]
    
    ConsumerA -->|"Gagal (Panic/Crash)"| Requeue["Requeue = true"]
    Requeue --> Head["Pesan Kembali ke Head Antrean"]
    Head -->|"Dikirim Ulang"| ConsumerB["Konsumen B Gagal Lagi"]
    ConsumerB --> Requeue
    
    ConsumerA -->|"Deteksi Limit Terlampaui"| Action["Drop / DLQ"]

Jika aplikasi konsumen kita merespon seluruh kegagalan ini dengan secara konsisten mengirimkan sinyal requeue = true ke broker, maka pesan racun ini akan memblokir baris terdepan antrean selamanya. Throughput antrean akan merosot menjadi nol, dan seluruh sistem asinkron kita akan mengalami kemacetan total.

Strategi Pendeteksian di Sisi Konsumen #

Untuk mencegah terjadinya lingkaran setan pengiriman ulang (infinite redelivery loop), aplikasi konsumen kita harus mampu mendeteksi secara programatis apakah sebuah pesan yang diterimanya merupakan pesan yang sudah pernah gagal sebelumnya. RabbitMQ menyediakan beberapa metadata penting yang dapat kita manfaatkan:

1. Evaluasi Menggunakan Flag Redelivered #

Setiap kali broker mengirimkan pesan ke konsumen, broker menyertakan flag boolean bernama Redelivered di dalam amplop metadata pesan (amqp.Delivery).

  • Jika pesan baru pertama kali dikirimkan sejak diterbitkan oleh produsen, flag ini bernilai false.
  • Jika pesan tersebut pernah dikembalikan ke antrean (karena konsumen sebelumnya crash, koneksi putus, atau mengirimkan NACK requeue), broker akan mengubah flag ini menjadi true sebelum mengirimkannya ke konsumen berikutnya.

Keterbatasan: Flag Redelivered hanya berupa boolean biner. Kita hanya tahu bahwa pesan ini pernah gagal, namun kita tidak tahu apakah ini kegagalan yang ke-2 atau yang ke-10.000 kali. Kita tidak bisa menetapkan kebijakan toleransi yang halus (misalnya: “coba lagi maksimal 3 kali sebelum dibuang”).

2. Evaluasi Menggunakan Header x-death #

Jika antrean kita terhubung dengan Dead Letter Exchange (DLX) untuk pola retry, setiap kali pesan mengalami kematian dan diarahkan ke exchange retry, broker RabbitMQ akan menyisipkan array metadata x-death pada header pesan.

Kita dapat memprogram konsumen untuk membaca panjang array x-death ini guna menghitung berapa kali pesan tersebut telah dialihkan melintasi antrean delay. Jika jumlah entri di dalam x-death melampaui batas ambang aman kita (misalnya panjang array > 3), konsumen dapat memutuskan untuk tidak melakukan retry lagi, melainkan langsung membuang pesan tersebut ke DLQ akhir.

Perbandingan Classic Queue vs Quorum Queue #

Keterbatasan pelacakan jumlah pengiriman ulang pada antrean RabbitMQ sangat bergantung pada tipe antrean yang kita pilih. Perbedaan arsitektural antara Classic Queue dan Quorum Queue dalam menangani metrik redelivery ini sangatlah kontras:

Pelacakan pada Classic Queue (Kurang Andal) #

Classic Queue tidak memiliki memori penyimpanan persisten internal untuk mencatat berapa kali suatu pesan individu telah dikirimkan ulang ke konsumen. Broker hanya melacak status in-flight pesan di dalam memori RAM lokal node tersebut.

Jika terjadi skenario di mana konsumen mengambil pesan, memprosesnya, lalu tiba-tiba mengalami crash keras (Out-of-Memory atau server mati mendadak) sebelum sempat mengirimkan konfirmasi, koneksi TCP akan putus. Broker Classic Queue mendeteksi putusnya koneksi dan mengembalikan status pesan ke antrean utama dengan flag Redelivered = true.

Namun, jika kemudian node broker RabbitMQ itu sendiri yang mengalami restart atau crash, seluruh informasi pelacakan in-flight di RAM tersebut akan hilang. Setelah broker menyala kembali, pesan tersebut akan dikirimkan kembali ke konsumen dengan status seolah-olah baru pertama kali mengalami redelivery, membuat pelacakan jumlah kegagalan menjadi tidak akurat.

Pelacakan pada Quorum Queue (Sangat Andal & Konsisten) #

Untuk mengatasi kelemahan fatal Classic Queue tersebut, Quorum Queue memperkenalkan fitur native pelacakan yang sangat tangguh bernama x-delivery-count. Properti ini berupa header integer yang disisipkan secara otomatis oleh broker ke dalam setiap pesan Quorum Queue.

Setiap kali broker mengirimkan pesan ke konsumen (baik pengiriman pertama maupun pengiriman ulang pasca koneksi terputus atau NACK requeue), broker akan menaikkan nilai counter x-delivery-count ini sebesar 1. Yang paling penting, nilai counter ini direplikasikan ke seluruh node replika di klaster RabbitMQ menggunakan konsensus Raft dan disimpan secara persisten di dalam log disk.

Artinya, meskipun konsumen crash berkali-kali secara brutal, server broker mengalami failover mendadak, atau terjadi pemadaman listrik total pada pusat data kita, nilai riil berapa kali pesan tersebut telah dikirimkan ulang tetap tercatat secara akurat 100% tanpa ada risiko kehilangan data pelacakan. Hal ini menjadikan Quorum Queue sebagai pilihan standar yang wajib digunakan untuk transaksi keuangan atau pemrosesan pesan transaksional kritis lainnya yang rentan terhadap bahaya poison message.

Cara Menentukan Ambang Batas Kegagalan (Thresholds) #

Saat mendesain kebijakan penanganan poison message, menentukan ambang batas pengiriman ulang maksimum (Max Delivery Limit) adalah keputusan desain yang sangat penting. Kita harus menyeimbangkan antara dua kebutuhan yang saling bertolak belakang:

  • Toleransi Terlalu Rendah (misal Max Delivery = 1): Jika kita menyetel batas maksimal pengiriman ulang hanya 1 kali (langsung dibuang jika gagal pertama kali), kita akan kehilangan kemampuan toleransi terhadap kesalahan transient. Gangguan jaringan sesaat selama 10 milidetik dapat menyebabkan pesan-pesan sehat terbuang secara prematur ke DLQ, meningkatkan beban kerja operasional manual tim support kita untuk memulihkan pesan tersebut.
  • Toleransi Terlalu Tinggi (misal Max Delivery = 50): Jika kita menyetel batas maksimal hingga 50 kali retry, kita membiarkan pesan racun membakar sumber daya CPU dan disk log selama puluhan menit sebelum akhirnya diisolasi. Hal ini mengurangi throughput sistem secara keseluruhan dan memperlambat deteksi adanya anomali sistem.

Rekomendasi Praktis: Di lingkungan produksi berskala besar, ambang batas maksimum pengiriman ulang yang ideal berkisar antara 3 hingga 5 kali percobaan. Batas ini dinilai sangat cukup untuk memberikan kesempatan bagi kesalahan transient jaringan atau database untuk pulih (terutama jika dikombinasikan dengan jeda waktu backoff), namun juga cukup responsif untuk langsung mengisolasi pesan-pesan racun dengan cepat ke DLQ sebelum mereka merusak kinerja antrean utama.

Implementasi Kode Go (Golang) #

Berikut adalah contoh program konsumen dalam bahasa Go yang dirancang khusus untuk memproses antrean bertipe Quorum Queue. Kode ini memanfaatkan header native x-delivery-count untuk mendeteksi poison message secara akurat. Jika pesan terdeteksi telah dikirim ulang lebih dari 3 kali, konsumen akan segera menghentikan proses retry dan melakukan pengalihan pesan secara aman ke Dead Letter Exchange (DLX).

package main

import (
	"context"
	"encoding/json"
	"log"
	"os"
	"os/signal"
	"syscall"

	amqp "github.com/rabbitmq/amqp091-go"
)

// OrderPayload merepresentasikan payload transaksi pembelian kita
type OrderPayload struct {
	OrderID    string  `json:"order_id"`
	ProductID  string  `json:"product_id"`
	Price      float64 `json:"price"`
}

func main() {
	// 1. Membuka koneksi fisik ke broker RabbitMQ
	conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
	if err != nil {
		log.Fatalf("Gagal membuka koneksi ke RabbitMQ: %v", err)
	}
	defer conn.Close()

	// 2. Membuat channel AMQP
	ch, err := conn.Channel()
	if err != nil {
		log.Fatalf("Gagal membuka channel AMQP: %v", err)
	}
	defer ch.Close()

	// 3. Deklarasi Topologi Jaring Pengaman (DLX & DLQ)
	err = ch.ExchangeDeclare(
		"order.dlx",
		"direct",
		true,
		false,
		false,
		false,
		nil,
	)
	if err != nil {
		log.Fatalf("Gagal deklarasi order.dlx: %v", err)
	}

	dlqArgs := amqp.Table{"x-queue-type": "quorum"}
	dlq, err := ch.QueueDeclare(
		"order.poison.dlq", // Antrean penampung poison message
		true,
		false,
		false,
		false,
		dlqArgs,
	)
	if err != nil {
		log.Fatalf("Gagal deklarasi poison queue: %v", err)
	}

	err = ch.QueueBind(dlq.Name, "order.failed", "order.dlx", false, nil)
	if err != nil {
		log.Fatalf("Gagal binding poison queue: %v", err)
	}

	// 4. Deklarasi Antrean Utama (Quorum Queue) terikat ke DLX
	mainQueueArgs := amqp.Table{
		"x-queue-type":             "quorum",
		"x-dead-letter-exchange": "order.dlx",    // Alihkan pesan mati ke DLX ini
		"x-dead-letter-routing-key": "order.failed", // Routing key tujuan di DLX
	}
	mainQueue, err := ch.QueueDeclare(
		"order.processing.queue",
		true,
		false,
		false,
		false,
		mainQueueArgs,
	)
	if err != nil {
		log.Fatalf("Gagal deklarasi main queue: %v", err)
	}

	// 5. Menetapkan Prefetch QoS untuk membatasi penumpukan data di konsumen
	err = ch.Qos(5, 0, false)
	if err != nil {
		log.Fatalf("Gagal menyetel Qos Prefetch: %v", err)
	}

	// Mendaftarkan konsumen
	msgs, err := ch.Consume(
		mainQueue.Name,
		"order-poison-detector",
		false, // manual ACK wajib
		false,
		false,
		false,
		nil,
	)
	if err != nil {
		log.Fatalf("Gagal registrasi konsumen: %v", err)
	}

	log.Println("[INFO] Konsumen aktif mendeteksi poison message. Menunggu data...")

	go func() {
		for d := range msgs {
			// A. DETEKSI POISON MESSAGE MENGGUNAKAN HEADER NATIVE x-delivery-count
			var deliveryCount int64 = 1
			if rawVal, ok := d.Headers["x-delivery-count"]; ok {
				// RabbitMQ mengirimkan x-delivery-count dalam format integer 64-bit (int64)
				if val, assertOk := rawVal.(int64); assertOk {
					deliveryCount = val
				}
			}

			log.Printf("[RECEIVED] Memproses Pesan ID: %s (Pengiriman Ke-%d)", d.MessageId, deliveryCount)

			maxDeliveryLimit := int64(3) // Batasi maksimal hanya 3 kali pengiriman
			if deliveryCount > maxDeliveryLimit {
				log.Printf("[POISON] Terdeteksi Poison Message pada ID %s! Menghentikan retry...", d.MessageId)
				
				// Kirimkan NACK dengan requeue = false agar broker langsung menyingkirkan pesan
				// ke exchange order.dlx yang akan meneruskannya ke antrean order.poison.dlq.
				err := d.Nack(false, false)
				if err != nil {
					log.Printf("Gagal mengirimkan NACK Drop: %v", err)
				}
				continue
			}

			// B. EKSEKUSI LOGIKA BISNIS PEMROSESAN DATA
			err := processOrder(d.Body)
			if err != nil {
				log.Printf("[WARN] Kegagalan pemrosesan pesan %s: %v. Mengirimkan NACK Requeue...", d.MessageId, err)
				
				// Kirimkan NACK dengan requeue = true untuk mencoba lagi
				// Nilai x-delivery-count otomatis ditambahkan oleh broker pada pengiriman berikutnya
				nackErr := d.Nack(false, true)
				if nackErr != nil {
					log.Printf("Gagal mengirimkan NACK Requeue: %v", nackErr)
				}
				continue
			}

			// Pemrosesan Sukses
			log.Printf("[SUCCESS] Sukses memproses Pesan ID: %s. Mengirimkan ACK...", d.MessageId)
			d.Ack(false)
		}
	}()

	sigChan := make(chan os.Signal, 1)
	signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)
	<-sigChan

	log.Println("[INFO] Menghentikan konsumen secara aman...")
}

// processOrder mensimulasikan kegagalan parsing JSON (kesalahan permanen)
func processOrder(body []byte) error {
	var order OrderPayload
	err := json.Unmarshal(body, &order)
	if err != nil {
		return err // Mengembalikan JSON parsing error
	}
	return nil
}

Anti-Pattern vs Solusi Praktis #

Kesalahan dalam penanganan poison message dapat memicu kelelahan pada tim operasional dan kegagalan klaster. Berikut adalah beberapa anti-pattern yang harus kita hindari:

Anti-Pattern: Mengabaikan Penanganan Panic (Catch-All Exception) pada Konsumen #

Menulis kode konsumen yang tidak dilengkapi dengan mekanisme recovery dari kondisi panic/crash. Jika ada pesan yang memicu null pointer dereference, proses aplikasi konsumen langsung mati seketika.

Mengapa ini salah? #

Ketika aplikasi konsumen mati mendadak akibat panic, broker RabbitMQ mendeteksi bahwa koneksi TCP terputus. Broker secara otomatis mengembalikan status pesan tersebut menjadi requeue.

Jika kita menggunakan manajer proses (seperti Kubernetes yang otomatis me-restart Pod yang crash, atau Systemd di server lokal), proses konsumen kita akan menyala kembali dalam beberapa detik. Konsumen baru ini akan langsung mengambil pesan terdepan antrean, yang tidak lain adalah pesan racun yang sama. Konsumen akan mengalami panic lagi, mati lagi, di-restart lagi, dan siklus crash ini akan terus berulang (Crashloop Backoff).

Kondisi ini tidak hanya menyia-nyiakan resource CPU kubernetes, tetapi juga memenuhi log file dengan ribuan stack trace panic yang identik, serta membekukan seluruh antrean bisnis utama.

Solusi Praktis #

Selalu bungkus fungsi pemroses pesan di dalam konsumen menggunakan blok pengaman recovery (defer recover() pada bahasa Go, atau try-catch blok global pada Java/TypeScript). Jika terjadi kepanikan tidak terduga:

  1. Tangkap panic tersebut agar aplikasi konsumen tidak mati (stay alive).
  2. Tulis log error secara detail beserta payload pesan penyebab masalah.
  3. Kirimkan Nack(false, false) secara sadar agar broker memindahkan pesan tersebut ke DLQ, membebaskan konsumen untuk memproses pesan-pesan sehat berikutnya dengan lancar.

Ringkasan #

  • Definisi Poison Message — Pesan rusak atau tidak valid yang selalu memicu kegagalan pemrosesan secara permanen di tingkat konsumen.
  • Bahaya Lingkaran Setan — Tanpa proteksi limit, pesan racun akan terus-menerus dikirim ulang ke konsumen secara instan, memicu lonjakan CPU 100% dan membekukan throughput antrean utama.
  • Pendeteksian Dasar — Kita dapat mendeteksi pengiriman ulang menggunakan flag boolean Redelivered bawaan AMQP atau menganalisis metadata pada header x-death.
  • Keunggulan Quorum Queue — Menyediakan counter native x-delivery-count yang direplikasikan secara konsisten di seluruh node klaster via Raft log ke disk, menjamin keakuratan pelacakan retry meskipun terjadi failover server.
  • Ambang Batas Ideal — Gunakan batas maksimum pengiriman ulang (Max Delivery Limit) berkisar antara 3 hingga 5 kali percobaan di lingkungan produksi.
  • Mitigasi Crashloop — Selalu gunakan penanganan recovery panic (defer recover) pada konsumen untuk mencegah crash aplikasi berulang-ulang akibat pesan rusak, dan alihkan pesan tersebut ke DLQ menggunakan requeue = false.

← Sebelumnya: Exponential Backoff   Berikutnya: Retry Pattern →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact