Day 8

Retry Queues, Dead-Letter Queues, and Failure Flow

আজকের lesson production survival-এর জন্য। সব failure same না; তাই retry strategy আর poison-message handling clean হওয়া দরকার।

Retry and DLQ

Failure Types

Failure type	Example	Action
Temporary	DB timeout, network glitch	retry
Permanent	invalid JSON schema, unknown required field	DLQ / reject
External slow dependency	payment provider lag	retry with delay


args := amqp.Table{
	"x-dead-letter-exchange":    "",
	"x-dead-letter-routing-key": "orders.dlq",
}
 
_, err := ch.QueueDeclare("orders.main", true, false, false, false, args)
if err != nil {
	log.Fatal(err)
}

Incident Thinking

Situation: একটি payment consumer downstream gateway timeout-এর কারণে fail করছে। Message requeue করা হচ্ছে, কিন্তু queue hot loop-এ চলে গেছে।

Goal: Safer redesign ভাবা।

What to think about:

immediate requeue same failure দ্রুত repeat করাবে
delay দরকার
max retry limit দরকার

সম্ভাব্য সমাধান দেখুন

Retry queue + TTL + DLQ strategy better। Temporary failure message কিছু delay পরে main queue-তে ফিরে আসবে। বারবার fail হলে DLQ-তে যাবে। এতে hot loop কমবে।

Poison message বলতে কী বোঝায়?

Checkpoint

নিজে explain করো: retry queue আর DLQ একই জিনিস না।

Retry queue = আবার চেষ্টা করার staging area
DLQ = normal flow থেকে আলাদা inspection area
Retry loop bounded না হলে system unhealthy হয়