A queue decouples the two services: the producer (sender) and the consumer (receiver) no longer need to run at the same time or be up at the same time. The producer hands off the work and returns quickly. This works even if the consumer is slow, busy or down. The messages wait in the queue until the consumer recovers.
A queue also gives you:
- Buffering for spikes. A burst of 10,000 orders becomes a backlog. Workers process it at a steady rate, so the service behind them is not overloaded. This is called the queue-based load levelling pattern.
- Simple scaling. To process faster, you add more consumers.
- Built-in retries for failed messages, and dead letter queues (DLQ: a separate queue for messages that keep failing).
The costs:
- The work becomes asynchronous, so the caller does not get the result immediately.
- Consumers must be idempotent (safe to run twice on the same message), because delivery is usually at-least-once.
- You add a broker (the queue server) that you must run and monitor.
Use a direct HTTP call when the caller really needs the answer now.
- A queue decouples the services, so they don't need to run or be available at the same time.
- A queue absorbs spikes, and consumers work at their own pace.
- You scale by adding more consumers.
- Queues give retries and a dead letter queue (DLQ) for failed messages.
- The costs are async results, the need for idempotent consumers, and one more component to run.