A customer taps Place order in a food-delivery app, and five things have to happen: the order is recorded, the card is charged, the restaurant is notified, a courier is assigned, and analytics is updated. Do all five inside the request and the customer waits for the slowest one, while an outage in any of them fails the whole order?

A message queue is a broker sitting between those steps: the checkout service durably hands work off and answers the customer, and something else picks that work up later. The rest of the field is what the handoff guarantees, what shape the message takes, and what goes wrong once more than one consumer is reading.

Queues appear in many system designs as soon as one request triggers downstream work. Placing the queue is only the first decision. You also need to explain what happens when a consumer crashes midway through processing, when events for one order finish out of order, when the broker fails, and when a growing backlog reveals a capacity limit.

Start by deciding which work can happen asynchronously. Then choose the message pattern and broker model before handling delivery, ordering, and failure.