Queues and message brokers, explained without the jargon

The advice here is unglamorous, which is probably why it gets skipped. Here is queues and message brokers without the vocabulary that usually surrounds it.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. It rarely shows up as a line item, which is exactly why it slips.

The short version

Queues absorb spikes that would otherwise take a system down. In practice this is a scheduling problem more than a technical one. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. In practice this is a scheduling problem more than a technical one.

Every queue needs a dead letter destination and someone watching it. Small and consistent beats large and occasional here. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Turning this into a decision

Ordering guarantees are weaker than most teams assume. Small and consistent beats large and occasional here. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

In practice

Most systems fail at the seams rather than inside any one component. 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

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.