Dabish Digital
Architecture

Queues and message brokers for small teams

There is no clever trick in this one, just a handful of decisions worth making deliberately. Most advice about queues and message brokers assumes a team that does not exist at your size. Here is the version that does not.

Most systems fail at the seams rather than inside any one component. If two people in the business would answer this differently, that gap is the actual problem.

What to keep

Queues absorb spikes that would otherwise take a system down. The cost of getting this wrong is rarely visible on the day it happens. The version that survives contact with a real deadline is the simple one.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. The cost of getting this wrong is rarely visible on the day it happens.

How we handle it

Ordering guarantees are weaker than most teams assume. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is the sort of thing that looks like polish right up until it costs you an enquiry.

In practice

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
  • 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.