We are building a web API and using nServiceBus for messaging under the hood for all asynchronous and long running processes.
Question is when we spin off a new version of the API should we use a new set of queues?
Like, for the API version 1,
- blobstore.v1.inbound
- blobstore.v1.outbound
- blobstore.v1.timeout
- blobstore.v1.audit
and for the API version 2,
- blobstore.v2.inbound
- blobstore.v2.outbound
- blobstore.v2.timeout
- blobstore.v2.audit
Or should we strive to use the same set of queues with multiple message formats and handlers (assuming change of requirements and evolving message formats)?
I am trying to understand pros and cons in the long run from the architecture standpoint. Having a separate set of queues gives the flexibility of building, deploying and managing different API versions in isolation without worrying about compatibility and sociability.
Personally I am leaning towards to the latter but the challenges around compatibility and upgrades are not clearly understood.
If you have dealt with a similar scenario in the past, please share your experiences, thoughts, suggestions and recommendations.
Your time is much appreciated!
The more frequent your releases, the less appropriate a queue-per-version strategy becomes, and the more important backwards-compatibility becomes (both in structure and in behavior).