Queues and message brokers: the questions we get asked most

This is one of those topics that looks small until it costs you something. The questions about queues and message brokers that come up most often on our calls.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Do we need to care about this?

Queues absorb spikes that would otherwise take a system down. Where this goes wrong is almost never a lack of knowledge. Check it against what you would want a competitor's site to get wrong.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. In practice this is a scheduling problem more than a technical one.

How do we know it is working?

Ordering guarantees are weaker than most teams assume. There is a version of this that is over-engineered, and it is worth avoiding. If two people in the business would answer this differently, that gap is the actual problem.

What this looks like day to day

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. 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

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