DLQ e gestione dei messaggi velenosi

Dead Letter Queue (DLQ) è una coda/topic isolata per i messaggi che non è stato possibile elaborare con un concertatore a tempo pieno dopo un determinato numero di tentativi o per ragioni tecniche/aziendali evidenti (schema non portatile, timeout, conflitto di versioni, ecc.). Messaggio velenoso (poison messagging) - Una scrittura la cui nuova elaborazione si conclude stabilmente con un errore e minaccia la stabilità del pipline.

Obiettivo DLQ: salvare lo SLO, localizzare il guasto, impedire il blocco del flusso principale e garantire la possibilità di analizzare e riprodurre in sicurezza (redwave).

1) Da dove vengono i messaggi velenosi

Schemi/contratti: modifiche incompatibili, campi obbligatori mancanti, tipi non validi.
Validazioni aziendali: duplicati, invarianti compromessi, eventi scaduti.
Ordine e causalità: è arrivato «Update» prima di «Create», correlazioni mancate, out-of-order.
Idampotenza: il nuovo trattamento genera effetti collaterali.
Dipendenze esterne: limiti/timeout limitati, API non disponibile.
Dati: corruzione del carico utile, codifica errata, eccesso di dimensioni.

2) Criteri di invio a DLQ

• È stato superato il livello di elaborazione del consumatore/worker.
• L'errore è stato classificato come difettoso (no-retryable): schema nefalide, nessuna risorsa critica, restrizione aziendale.
• Messaggio deadline scaduto (TTL/expiration).
• Il criterio circuito breaker o admision control per questa chiave/tenante ha funzionato.
• Soluzione esplicita dell'operatore (eject manuale dal flusso principale).

3) Topologie e pattern DLQ

Per-queue DLQ: ogni coda/top ha un DLQ diverso. Semplice e trasparente.
Central DLQ (parcheggio lot) - Un parcheggio condiviso per casi complessi è utile per strumenti di analisi unificati.
DLT (Dead Letter Topic) - Per i bus orientati logici (event log), un topic separato con i metadati della causa di guasto.
Quarantine - Buffer di quarantena con accesso rigido e recupero PII per analisi manuali.
Shadow-stream: duplicazione dei messaggi problematici in ombra per esperimenti di fissaggio sicuri.

4) Metadati obbligati ad accompagnare il DLQ

• Causa di errore: codice/classe di errore, stack/trace id.
• Contesto retrae: «attempt», «maxAttempts», «first _ seen _ ts», «last _ attempt _ ts».
• Correlazione: «trace _ id», «span _ id», «tenant _ id», «entity _ id», chiave di partitura.
• Offset/partition/sequence originale (per i pneumatici da tana) o messaggino-id.
• Contratto/schema/versione del carico utile.
• Idempotency-key/Richiest-id (se disponibile).
• Origine di instradamento: nome della coda/top, gruppo di consolle.

5) Criteri di retraine per il DLQ

• Brevi retrai della consumatrice: 'maxAttempts' 2-5, exponential backoff + jitter, caps su concertency.
• Backpressure cooperative: riduzione della concorrenza quando aumentano gli errori.
• Classificazione degli errori: retryable ('5xx', timeout) vs no-retryable (convalida, schema mismatch).
• Code posticipate (delay queue): 5s → 30s → 2m per guasti temporanei.
• Isolamento per-key - Se «rumorizza» una chiave specifica, non bloccare l'intera partitura.

6) Redrave sicuro (rifornimento dal DLQ)

Redrave è un ritorno controllato dei messaggi dalla DLQ all'elaborazione.

1. Verifica Fix: Redrave solo dopo la correzione del codice/configurazione/schema o dopo il ripristino delle dipendenze esterne.

2. Idampotenza: i processori devono essere resistenti alla ripetizione (upsert, effetto-tolurante).

3. Deduplicazione per «idempotency _ key »/« messaggistica _ id »/« business _ key».

4. Dosaggio e finestre: batches per N messaggi, rate-limit per redrave, «finestre» per ora/partitura.

5. Convalida locale - Verifica rapida dello schema prima della redrave (reject delle prime valigette non calde).

6. Priorità: il redrave non deve sovrascrivere il traffico prolungato (priorità bassa dei worker/pool separato).

7. Osservabilità: metriche separate e roulotte per redwave; Report risultati (successo/ripetizione DLQ/perdita).

7) Semantica di consegna e ordine

At-least-once è la modalità più frequente che richiede idipotenza e deduplicazione.
At-not-once - DLQ può essere disattivato; Rischio di perdita. Utilizzare solo se le perdite sono valide.
Exactly-once (efficiente): consente di ottenere transazioni e deduplicazione nello storage aziendale costoso e specifico.
Ordine: il DLQ di solito interrompe l'ordine per una specifica chiave/partitura. Se l'ordine è critico, riduce la chiave e la sequenza.

8) Schemi, contratti e validazione

Schema registry/contratti - versioning chiaro, evoluzione con backward/forward-compatibilità.
Convalida di ingresso: controllo a basso costo tramite JSON Schema/Protobuf/Avro prima dei passi difficili.
Criteri di incompatibilità: se il campo «spezzante» è immediatamente in DLQ con il codico'SCHEMA _ INCOMPATILE '.
Redaction PII: memorizza solo ciò di cui hai bisogno in DLQ; maschera i campi sensibili.

9) Idampotenza e deduplicazione

Idempotency-key - Formare su un produttore di «significato aziendale» (tenant + entity + operation + ts-bucket).
Registri di deadup memorizzare le ultime chiavi «N» con TTL; Ricorda l'effetto dell'operazione.
Upsert/merge: evitare «insert-only» senza limiti.
Effetti side - Per le chiamate esterne, registrare e verificare la «ripetizione» prima della chiamata.

10) Osservabilità e SLO

• DLQ rate (msg/s), numero di messaggi, età media/mediana nel DLQ.
• Successo di Redriva (%), nuovo DLQ.
• Classificazione delle cause: schema, validation, timeout, dipendency, unknown.
• p95/p99 latitanza del trattamento del flusso principale vs in redrave.
• Dimensioni DLQ, rischio di sovraccarico.

• I tag obbligatori sono «messaggino _ id», «entity _ id», «tenant _ id», «attempt», «reason», «redrive _ batch _ id».
• Traccia del ramo DLQ dall'origine al nuovo successo.

• Percentuale di messaggi elaborati correttamente per X% in T minuti.
• Tempo di indagine e correzione per la valigetta DLQ ≤ Y ore.
• Età massima del messaggio nel DLQ ≤ Z ore (con alert).

11) Sicurezza e conformità

Accesso ai più piccoli privilegi: redrave solo agli operatori/playbook.
Controllo: chi e quando ha innescato redrave/rimozione/modifica dei metadati.
Ripristino: quando si trasferisce al DLQ centrale, rimuovere i segreti PII in eccesso.
Data di conservazione separata e criteri di eliminazione per la DLQ.

12) Multi-tenenza

Tag «tenant _ id/plan»: distingue i limiti, le priorità di redwave, i report.
DLQ o partizioni per tenanti - Per evitare che un client «rumoroso» segni una DLQ comune.
Bollo/quote - Tenere conto della quantità di DLQ e del costo di redriva in usage.

13) Modelli di configurazione (esempio)

yaml consumer:
max_attempts: 4 backoff:
strategy: exponential_full_jitter initial_ms: 200 max_ms: 5000 classify_errors:
retryable:  [TIMEOUT, DEP_UNAVAILABLE, 5xx]
nonretryable:[SCHEMA_INCOMPATIBLE, VALIDATION_FAILED, DUPLICATE]
concurrency_caps:
per_partition: 8 per_tenant: 50

dlq:
type: topic name: myapp. events. dlq metadata:
include: [reason, stack, attempt, first_seen_ts, last_attempt_ts, schema_version,
tenant_id, entity_id, trace_id, source_topic, partition, offset]
retention_hours: 168 pii_redaction: true

redrive:
mode: batch batch_size: 500 rate_limit_per_sec: 50 priority: low validate_schema_before_redrive: true idempotency:
dedup_ttl_hours: 24 ordering:
by_key: true

14) Playbook operativi (runbooks)

1. Crescita anomala del DLQ: abilita il throttling del provider, analizza le cause top, controlla le release/schemi.
2. Schema mismatch: reimpostazione/fissazione dello schema, migrazione dell'adattatore, redrive dopo la convalida.
3. La dipendenza esterna non è disponibile: pausa dei retrai, attivare la coda delay, redrive dopo il ripristino.
4. DLQ ripetuti dopo ridriva: attivare il processore/simulatore shadow, verificare l'idampotenza, restringere il batch.
5. Download DLQ - Evacuare l'archivio-storage, attivare il redrave selettivo per chiavi/motivi.

15) Test e caos

Iniezione di errori: schema-break, convalida, timeout, 1-N «appiccicoso».
Redrave di massa: verifica del dosaggio e dell'impatto sul profumo.
Out-of-order sequenza: ensure corretta per le chiavi.
Corruzione del carico utile, convalida e rifiuto sicuro.
Recupero dalla caduta del redrave-worker: idampotenza delle operazioni batch.

16) Errori tipici

La mancanza di metadati nella DLQ non può essere clusterizzata e ridotta in modo sicuro.
Un redrave di massa senza limiti è stato ripetuto il degrado della produzione.
Non c'è idampotenza/deducibilità, riprese e effetti collaterali.
Miscelare il PII in un DLQ centrale senza sanare.
L'assenza di schemi/contratti è una sorpresa per l'evoluzione dei messaggi.
Unico DLQ condiviso senza partizionamento per tenanti/chiavi.
Retrai infiniti invece di DLQ precoce per errori non-retryable.

17) Ricette veloci

Flusso aziendale normale: 3-4 tentativi, backoff esponenziale con jitter, classificazione precoce degli errori, DLQ con metadati completi.
Eventi critici (pagamento): idermotenza rigorosa, brevi timeout, minimo tentativi, DLQ rapido e analisi manuale.
Ridrave di massa dopo il file: small batches (100-500), rate-limit, pool di worker separato, monitoraggio del successo> 95% prima di aumentare la velocità.
Multi-tenant: limiti per-tenente per redrave, rapporto sui top client generatori DLQ.

Conclusione

Il DLQ non è un cestino, ma un circuito di affidabilità controllato. Regole di ingresso chiare, metadati ricchi, idoidpotenza e deduplicazione, reading sicuro e dosato, disciplina dei diagrammi e osservabilità trasformano i messaggi velenosi da una minaccia per l'SLO a un processo di ingegneria gestita, con playbook comprensibili, costi previsti e impatto minimo sugli utenti.