In a point-to-point queue with multiple consumer instances attached, how does the broker typically decide which consumer receives which message, and what ordering guarantees (if any) survive this distribution?

## One queue, many consumers Once more than one consumer instance is attached to a single queue, the broker needs a policy for handing out messages, and that policy directly determines what ordering guarantees survive. ## Two ways to hand a message out **Mechanism.** There are two common dispatch strategies. 1. **Broker-push with flow control.** The broker pushes messages to connected consumers, typically round-robin, but respects a prefetch count (RabbitMQ calls this QoS/prefetch) so a slow consumer doesn't get flooded with more unacknowledged messages than it can handle — the broker skips a busy consumer and gives the next message to whichever consumer currently has capacity. 2. **Consumer-pull.** Consumers actively poll the broker for the next batch of messages, and whichever consumer polls first gets served next — Amazon SQS works this way, using a visibility timeout to hide a message from other pollers once it's been handed out, so it isn't picked up twice while being processed. In both models the effect is the same: which consumer processes which message is determined by consumer availability and timing, not by any fixed assignment. ## Why the pattern earns its place It exists because this is the entire point of competing consumers — to let you add horizontal capacity by adding worker instances, and have the broker automatically load-balance work across them without any coordination logic in your own code. A slow message doesn't block a fast one behind it if the fast one can be picked up by a different, idle worker. This is precisely how you scale queue-based work: throughput scales roughly linearly with consumer count until you saturate the downstream resource (DB, API, etc.) the consumers are calling. ## The ordering you give up That is the trade-off: as soon as messages are handed to whichever consumer is free, global FIFO ordering across the queue is lost. Message A published before message B may finish processing after B if A landed on a consumer that's momentarily slower (busy with a prior message, GC pause, network hiccup) while B landed on an idle one. - For many workloads this is fine or even desirable — independent, unordered jobs like resizing an image or sending an email. - But for workloads where order matters within a logical stream — e.g., applying balance-changing events to the same account in the order they happened — naive competing consumers will corrupt the outcome. The standard fix is **partitioning by key**: route all messages sharing a key (account ID, order ID, aggregate ID) to the same partition/sub-queue/consumer, so parallelism happens across keys while order is preserved within a key. - **Kafka** implements this natively via partitions and a partition key. - **SQS FIFO queues** implement it via message group ID, guaranteeing in-order, exactly-once-per-group delivery within a group while still allowing different groups to be processed in parallel by different consumers. ## Failure modes in production 1. **Assuming a standard queue preserves order.** A very common bug is a team assuming a standard (non-FIFO) queue preserves order because it usually does in low-traffic testing, then seeing out-of-order processing appear under production load once multiple consumers are added or one consumer occasionally lags — showing up as, for example, an order-cancelled event being processed before the order-created event that logically preceded it, corrupting downstream state. 2. **Over-partitioning.** A second failure mode is over-partitioning: keying by something too granular (like a random request ID) gives perfect ordering per key but no meaningful load-balancing benefit over having no partitioning at all; keying too coarsely (a single global key) accidentally serializes all consumers behind one, defeating the purpose of competing consumers entirely — a common self-inflicted bottleneck. 3. **Prefetch set too high.** A third failure mode: prefetch set too high on a push-based broker (e.g., RabbitMQ) lets one consumer hoard a large batch of messages, go slow or crash, and hold up throughput even though other consumers are idle and starved for work — tuning prefetch to roughly a handful more than what one consumer can process per ack round-trip avoids this. ## Partitioning in practice A concrete example: a payments platform processing per-account ledger events uses Kafka with account ID as the partition key. Ten partitions let ten consumer instances process ten different accounts' events fully in parallel, each achieving strict ordering for its own accounts' events (deposit, then withdrawal, then fee, processed in that order), while overall throughput scales with partition/consumer count. If the same events were pushed onto a single unpartitioned SQS standard queue with ten competing consumers, throughput would be similar, but a withdrawal could occasionally be processed before its preceding deposit, potentially causing a false insufficient-funds rejection — exactly the class of bug key-based partitioning exists to prevent.