Three myths about queues and message brokers

It comes up on almost every project, usually later than it should. A few things about queues and message brokers that get repeated more often than they get checked.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. If two people in the business would answer this differently, that gap is the actual problem.

“It only matters for big sites”

Queues absorb spikes that would otherwise take a system down. This is the sort of thing that compounds, quietly, in both directions. Budget a little time for it every quarter and it never becomes a project of its own.

“We can deal with it after launch”

Sometimes true, usually expensive. Where this goes wrong is almost never a lack of knowledge.

“Our platform handles it”

Ordering guarantees are weaker than most teams assume. None of that requires a large budget, only a decision and someone to own it. If two people in the business would answer this differently, that gap is the actual problem.

The short version

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
• Every queue needs a dead letter destination and someone watching it — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.