Message queues.
A to-do inbox between two services, so work is not dropped when one of them is busy.
When one service needs another to do something, the simple way is to call it directly and wait for it to finish. That works until the second service is slow, busy, or down — then the first one is stuck waiting too.
A message queue sits between them like an inbox. The sender drops a note and walks away; the receiver picks notes up whenever it is ready.
- Still waiting…1
The direct way: one service calls another and waits. If the other is slow, the caller is stuck too.
- There — done with my bit.2
Put an inbox between them. The sender drops a note and immediately gets on with its day.
- 3
The note waits safely in the queue, even if the receiver is busy or briefly down.
- 4
When it has capacity, the receiver pulls the next note and does the work at its own pace.
- Done. Clear it.5
Only once the work is finished is the note removed — so a crash mid-job loses nothing.
- 6
A sudden flood piles up and gets worked through steadily, instead of crushing the receiver all at once.
Decoupling is the real win
The sender and receiver no longer have to be fast, healthy, or even running at the same time. If the receiver crashes, messages pile up safely and get processed when it comes back. If you need more throughput, you add more receivers pulling from the same queue.
This makes systems far more resilient: a slow email service no longer slows down the checkout that triggered the email.
Smoothing out spikes
A queue also acts as a shock absorber. A sudden flood of requests piles up in the queue and is worked through at a steady pace the receivers can handle, instead of crushing them all at once. The trade is that work becomes asynchronous — it finishes a little later, not instantly — which is fine for things like sending emails, resizing images, or generating reports.