A practical checklist for queues and message brokers
Teams tend to reach for this after something has already gone wrong. Run through this the next time queues and message brokers comes up.
Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
The checklist
- Queues absorb spikes that would otherwise take a system down
- Every queue needs a dead letter destination and someone watching it
- Ordering guarantees are weaker than most teams assume
- Someone is named as the owner
- There is a date to review it again
Why it matters
Queues absorb spikes that would otherwise take a system down. The teams that handle this well are rarely the ones with the biggest budgets. It rarely shows up as a line item, which is exactly why it slips.
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
- Ordering guarantees are weaker than most teams assume — 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.