The order service sends a message to the broker and receives an acknowledgement. That sounds successful. Yet the warehouse has not created a picking task, and the customer is already asking support where the order went. Accepted by transport is not the same as completed by the business.
A message broker is useful when a sender and a receiver should operate at different speeds or tolerate each other's temporary unavailability. It reduces direct coupling; it does not make the end-to-end workflow reliable by itself.
What a broker removes
With a direct request, the order service waits for the warehouse. If the warehouse is down, the call fails or times out. Through a durable broker, the service can enqueue work while fulfilment processes it later.
That is useful during spikes: the queue buffers work arriving faster than one consumer can handle it. But if arrival rates stay above processing capacity, the queue is not a capacity solution. It is a growing backlog — ideally one the team can see.
A work queue is not the same as an event feed
“Pick this order” is work assigned to an executor. Often one worker in a group should perform it. “Order confirmed” is a business fact that several independent subscribers — fulfilment, notifications and analytics — may consume.
Queues and publish/subscribe systems differ in their retention and delivery semantics. Before choosing a technology, decide who owns the work, how many parties must see the message and whether the event must be available for replay.
What the transport does not promise
A consumer may complete its work and then crash before acknowledging the message. Delivery may repeat. Messages may be delayed, fail processing or arrive in an unexpected order. Exact guarantees depend on the chosen transport, but the business side effects still need to be safe under its failure modes.
A repeatedly failing message may end up in a Dead Letter Queue. That is not a completed order. Someone must examine the exception and decide how to recover.
And a broker alone does not close the gap between committing an order to the database and publishing its message. That is a separate dual-write problem, commonly addressed with a Transactional Outbox.
Where the operating cost appears
Message brokers need monitoring, retry rules, schema compatibility and recovery procedures for prolonged consumer outages. The company must support another operational component that can hold real customer obligations.
I would ask not only how many messages the system processes, but how many business operations are unfinished, how old they are and who owns recovery. A high-throughput broker with a pile of stuck orders is not much of a business win.
Use a broker when independent pacing and failure isolation solve a real product problem. It moves the responsibility for finishing work; it does not remove that responsibility.