Message Ordering
The guarantee about the sequence in which messages are delivered — normally per-partition or per-group only, and lost the moment consumption is parallelised.
Global ordering across a queue is rarely offered and never free, because it requires a single sequential consumer, which caps throughput at what one consumer can do.
What real systems offer instead is scoped ordering: Kafka guarantees order within a partition, SQS FIFO within a message group, Service Bus within a session, RabbitMQ within a queue with a single consumer. The scope is chosen by a key, and choosing that key is the design decision — order by customer, by account, by conversation, by aggregate root. Related messages share a scope and are ordered; unrelated ones are parallel.
Two things that silently destroy ordering. Competing consumers on the same scope: two consumers processing messages for the same entity concurrently will finish in either order regardless of delivery order. And retries: a failed message that is retried after later messages have been processed arrives out of order by definition, which is why ordered processing usually requires stopping the partition on failure rather than skipping ahead.
The pragmatic alternative is to design handlers to be order-insensitive — carry a version or timestamp in the payload and ignore anything older than what has already been applied.