Acknowledgment, Redelivery, and the Reordering Trap (Figure 12-2) Diagram

A broker removes a message from the queue only after the consumer explicitly acknowledges it
If the connection closes or times out without an ack, the broker assumes the message was never processed and delivers it again
The message may in fact have been fully processed with only the ack lost in the network — handling that case needs idempotence or an atomic commit protocol

Consumer 2 crashes while processing m3 at the same time as Consumer 1 processes m4, so the redelivered m3 lands on Consumer 1 after m4
Consumer 1 processes messages in the order m4, m3, m5 — m3 and m4 are not processed in the order Producer 1 sent them
Even where JMS or AMQP standards require ordered delivery, load balancing combined with redelivery inevitably reorders messages
The fix is a separate queue per consumer (no load balancing) — or accepting reordering when messages are completely independent

A badly serialized message (say, a JSON object missing a required key) crashes every consumer that receives it, so it is never acknowledged
The broker keeps resending it: with strong ordering the stream makes no further progress; otherwise resources are wasted on messages that will never be acked
A dead letter queue (DLQ) moves the poison message aside to unblock consumers; monitoring alerts an operator to drop, fix, or re-publish it