What's a typical versioning strategy for RabbitMQ?

Question

I've started working on a new project and we've been asked to build the system as a series of micro services, using RabbitMQ as a communication layer between them.

When developing REST APIs I tend to favour using the accepts HTTP header to control versioning and I see that you can use a header exchange in RabbitMQ to route messages in a similar way. However, as this is purely an internal messaging system, I'm not sure if the added complexity of a header exchange is really worth the while?

What is a typical setup for versioning RabbitMQ messages? It seems to me the options are:

1. New vhost for each version
2. Each Exchange has the version in the name (eg. MyExchange-v1, MyExchange-v2, ... etc.)
3. Queues are versioned
4. Routing keys are versioned (myroute-2.1.*)
5. Use a header exchange

Thanks for any input you may have.

Answer 1

I'd go with routing key version system for 2 main reasons:

Consumers will be able to bind (via queues of course) to their compatible versions via multiple bindings. Using semantic version (http://semver.org/) standard would be leveraged here via asterix and hash criteria.

You're not bound to using Rabbitmq as routing key is a standard function of AMQP