[danesparza]

Ordering is too expensive. Don't ever count on it when using an asynchronous queue. It's akin to storing session in a cache -- you're mixing your metaphors.

A queue should NEVER drop messages - otherwise it's a shit queue. Or you have a bug in your application code that needs to be fixed.

Poison messages are DEFINITELY A SMELL. This means you essentially have a broken interface contract. The code that is adding messages is expecting one thing -- code that is processing messages is expecting a different thing. It needs to be fixed by clearly documenting your message queue expectations and fixing your code. Most likely you need to add clear expectations for the lifetime of a message.

[JensRantil]

...it might be a smell, but they sure are bound to happen eventually; Corrupt user state or unhanded corner cases etc. Better plan for that in advance.

[dev_by_day]

This is why I prefer putting the "bad" message into a deadletter queue instead of dropping it entirely(and alert on messages going into this queue). This unblocks the queue so it can continue working and allows one to decide if it should be dropped or re-processed.

[User23]

> Ordering is too expensive. Don't ever count on it when using an asynchronous queue

In a field where precision is absolutely necessary, it's unfortunate to use the term queue to describe something that is not a queue.

[gkop]

Curious, what's your definition of queue?

[sam0x17]

By definition a queue is FIFO, which requires preserving ordering, or else you could end up with FIRO (first in, random out)