Best practice for ensuring name uniqueness/correctness in message queues in a microservice architecture/distributed system

Question

I was wondering what a good solution would be for ensuring that queue-names are entered correctly and are only used by the correct applications in a large system which uses message queues to exchange messages.

We have a large system written in Java and Apache Camel. It is split into several microservices where they use message queues to communicate with each other. The queue names are as of now strings, which tend to get pretty simple, like "incupdate" or "inccreate". When the system continues to grow and we continue to add more services I am worried that someone is going to reuse a queue-name that already exists, which would create bugs that would not show up in local testing and would be hard to debug. An easy solution to this is to simply add the service name as a prefix to the queue-name, this would ensure uniqueness between the services.

But I was thinking, "Why not take it a little further"? What if I created a reference, that all services had access to, for example an enum, where each service would only use entries in the reference as the queue-names? This way it would not only ensure uniqueness, but it would also ensure correctness (for example typos in queue-names). And it would also provide code-highlighting for wherever each queue-name is used.

Do you have any solutions or suggestions for a problem like this? Is the "reference"-solution viable at all? I can see one problem with it, and it's that each service actually has to have access to the enum, which means injecting it from somewhere. I think we could use maven or spring for this, but I am not sure.

Answer 1

I designed our system to use a combination of the environment name and the fully qualified name class name of the object that was serialized into the body of the messages in the queue, the machine name and the application name.

There is no mix up between messages from say 'Staging' and 'Test' environments because the environment name is part of the queue name. Note that we run 'Integration' and 'Test' environments on the same machine.

In our system every application knows whether it is running in 'Development', 'Test' or whatever, and any application that produces or consumes a particular queue needs to already have access to the class that is serialized into the message body, and can therefore compute the queue name accurately without additional configuration.