This is the story of a message broker filled with message queues. But how do you find your way through all this tangle?
In an enterprise context, the message broker is often an entity shared between domains. Multiple applications (or even teams) share the same broker, using different queues. Most of the time, the PROD broker is separated from TEST and BUILD environments to avoid unfortunate side effects.
Even so, the big question is: how to effectively name your queues to keep track?
Information to include
Here are some common pieces of information I personally like to find:
- Environment where the queue is used: PROD, UAT, DEV
- Responsible team for the message queue: the one you’ll contact to consume or push messages
- Domain of the message queue: what does this queue contain / what’s the destination of messages
Most queues serve very specific purposes, whether it’s a usage pattern or a recurring use within your architecture. In those cases, I really like adding the pattern name as a suffix.
- Retry: messages that didn’t go through and will try again
- Dead Letter Queue (or dlq): the cemetery of error messages, quite handy for reprocessing messages one by one when an issue occurred (a retry that really won’t pass, an execution issue that breaks the algorithm for example).
- Resiliency / buffer: buffer queues that absorb the load.
- And surely many other uses you have at your place! (priority queues for example, business events…)
Queues contain messages that follow a very specific data structure. Yes, it’s an API. If the message structure evolution induces a breaking change at production or reception level, then the version must be different. For me, this is useful information to specify on the message queue: what structure I respect.
- Version of messages: in a JSON-type approach where adding fields isn’t breaking, only the major version interests me. If you follow a more rigorous approach where adding becomes problematic, the complete version seems necessary.
Some constraints however:
- Watch out for max name length: it depends on your tools.
- Which separator to choose? Same thing, it depends on your tools.
The result by example
Which gives us:
<environment>.<responsible-team>.<domain>.<pattern>.<version>For example:
dev.team-marketing.booking.resiliency.v1What about automated tests?
When running automated integration tests, it may be necessary to create message queues on the fly. In those cases, the environment is clearly specified (as mentioned earlier), and I really like adding a UID as suffix to be able to run two tests simultaneously. The UID can be a UUID, or a concatenation of an execution context, a test identifier and a timestamp / temporal data for example.
Such as:
e2e.team-marketing.booking.resiliency.v1.runner-1.test-13.20250127T1112Some brokers allow automatic deletion of queues after a certain period of inactivity. Otherwise, you can rely on the naming structure to clean up everything that’s no longer needed and slipped through the cleanup steps.
