The Teaching Hub
DB: …

Reliability: DLQ & Retry

Ack/Nack, backoff e Dead Letter Queue: quando un messaggio fallisce, deve finire in un luogo visibile — non sparire nel vuoto.

Approfondimento

Definizioni, contesto e collegamenti tra concetti — leggi prima del palcoscenico interattivo se parti da zero.

Ack, nack, retry e backoff

Un consumer elabora un messaggio e poi conferma (ack) al broker. Se fallisce, può nack con requeue: il messaggio torna in coda. Senza limiti, un messaggio “tossico” blocca il throughput o crea loop infiniti.

Backoff esponenziale con jitter riduce thundering herd. Un massimo di tentativi e una dead letter queue (DLQ) isolano i fallimenti persistenti per analisi umana o reprocessing controllato.

Idempotenza e DLQ

Con at-least-once, la stessa logica di business può eseguire due volte: usa idempotency key, vincoli DB unici, o tabella di deduplicazione. In DLQ, annota `failureReason`, contatore retry e correlazione per capire la radice.

Monitora il tasso DLQ come segnale di prodotto: picchi possono indicare deploy rotto, schema incompatibile o dipendenza esterna instabile.

Palcoscenico

Producer
Coda principale
DLQ
msg

Messaggio in coda: premi “Elabora (fallisce)” per simulare un consumer fragile.

Contratto e codice

Schema JSON basato su CloudEvents 1.0, poi snippet server e client.

{
  "specversion": "1.0",
  "source": "/orders-service",
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "time": "2026-05-13T12:00:00.000Z",
  "datacontenttype": "application/json",
  "type": "com.example.messaging.dlq",
  "data": {
    "originalType": "com.example.payment.charge",
    "failureReason": "timeout",
    "retryCount": 3,
    "deadLetter": true
  }
}

Lab: backoff e decisione DLQ

Policy dichiarativa: dopo N tentativi con backoff esponenziale, marca per DLQ. Collegalo a metriche in produzione.

Caricamento playground…