Il termine appropriato per il problema che stai affrontando è "elaborazione dei messaggi velenosi". Le code di messaggi non recapitabili vengono in genere utilizzate dai sistemi di messaggistica per i messaggi non recapitabili. Un messaggio veleno è uno che un'applicazione client non può elaborare correttamente. Una 'coda messaggi velenosi' è una coda che è configurata per ricevere questi messaggi al fine di impedire che un messaggio venga letto e ripristinato indefinitamente. Questa è una buona pratica al fine di evitare che una richiesta errata causi il backup dei messaggi e il superamento della profondità della coda che inizierà a causare errori a monte.

Nel caso specifico in cui si è interessati a dove una applicazione downstream è offline, una soluzione facile è interrompere l'elaborazione dei messaggi sulla coda. Ci sono un paio di problemi con questo. Il principale è che se hai un volume elevato di messaggi in arrivo, puoi riempire la coda. Un altro potenziale problema è che se quella coda non è persistente, avere un sacco di messaggi seduti in esso ti mette a rischio di perdita di dati.

La mia esperienza con le soluzioni di messaggistica mi porta a questa raccomandazione generale: non fare affidamento sulle code per prevenire la perdita di dati. Indipendentemente da ciò che il venditore sostiene di "consegna garantita", ci sono così tante insidie e sfide nel rendere questo sistema a prova di perdite. Se è necessario assicurarsi che qualcosa arrivi, è necessario disporre di un archivio permanente in cui si conservano informazioni sufficienti per poter rigenerare un messaggio in caso di perdita. Spesso questo è in un database. Questo è simile a quello che avevi proposto, ma invece di spingere i messaggi a un DB quando vengono letti dalla coda, si mantiene un DB al punto di origine. Inoltre, suggerirei un approccio di tipo contabile di registrazione (almeno) dello stato finale di ogni record in quel negozio. Se hai bisogno di eliminare i dati, puoi farlo in un secondo momento.

Potrebbe sembrare che, se lo fai, le code sono irrilevanti, ma non è questo il caso. Le code sono un ottimo modo per spostare ed elaborare i messaggi in un sistema distribuito ed evitare contese. Usando un libro mastro DB con le code, ottieni il meglio da entrambi i mondi.

Comprendo le tue preoccupazioni al riguardo, ma direi che sì, è necessario estrarre i messaggi morti dal sistema di accodamento.

Il mio unico motivo per dire questo è questo sentimento:

maybe even reject some valid messages until we talk with the support team

Una coda di messaggi non recapitabili è ottima per le eccezioni o la gestione di un'analisi di un componente, ma l'aspettativa è che dopo aver risolto il problema è possibile rieseguire questi messaggi e questi scorreranno correttamente.

Ma sembra che tu abbia bisogno di un intervento manuale e possibilmente di modificare singoli messaggi come parte del tuo processo. Vale a dire che è normale che un gruppo di persone passi regolarmente a questi dati, discuta con la terza parte sulla loro validità, eventualmente modifica alcuni dati e invia di nuovo.

Se davvero hai questo requisito, allora direi che devi deserializzare il messaggio in qualche applicazione che gestisce quel processo. Compreso presumibilmente uno strato di persistenza e un'interfaccia utente corretta. Non puoi lasciarlo solo alle persone che modificano JSON e spostarti manualmente con la configurazione della coda.

Quindi andrei molto più lontano che la soluzione suggerita di un database con JSON, che sono d'accordo, non è affatto diversa dal DLQ.

Forse potresti dire loro "Guarda, se queste sono davvero cose che ci aspettiamo che accadano e che sia un requisito reale , allora dovremmo fare una soluzione completa. siamo più a loro agio rispetto alle code, quindi dovremmo fare tutto nei database '