Why queues and message brokers matters more than it looks

This is cheap to get right at the start and expensive to retrofit. Queues and message brokers is easy to treat as a detail, and that is exactly why it is worth a few minutes of attention.

Most systems fail at the seams rather than inside any one component. It rarely shows up as a line item, which is exactly why it slips.

What it costs to ignore

Queues absorb spikes that would otherwise take a system down. That sounds obvious written down. It is still the thing most often skipped. If it only works because one person remembers to do something, it does not work yet.

Every queue needs a dead letter destination and someone watching it. The teams that handle this well are rarely the ones with the biggest budgets. Assume whoever inherits this will have half your context and none of your patience.

Where it usually goes wrong

Ordering guarantees are weaker than most teams assume. There is a version of this that is over-engineered, and it is worth avoiding. If it only works because one person remembers to do something, it does not work yet.

How to tell if yours is fine

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Three things worth confirming about queues and message brokers before you move on:

• Someone can say what the current setup is without going to look
• Queues absorb spikes that would otherwise take a system down — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.