I have a service broker application that currently has 5 or 6 queues on two servers.
The general workflow is:
- User populates some tables
- User fires stored proc which puts a message into a header queue indicating there is work to be done
- Broker reads from this header queue and creates a potentially large number of messages to send to Server B
- Messages all go to 1 queue
- In this queue, message is examined and unbundled, payload is run and a response is collected from another set of procs/tables that we interact with
- Response message is created and sent back to Server A
- Response messages go to a special queue and are used to update tables the user populated at the top
- End dialog messages are read from the initiator queue and used to update another table that tracks the progress of a header record (i.e. 50 out of 100 messages processed)
- When we detect that the header record has been entirely processed, a new message is sent to another queue that sends a notification email
I've had a recommendation to consolidate some of those queues on Server A and I'm not sure what the best practice is for this. Two of the queues will have a relatively high volume of message processing, and the email queue will be be pretty slow.
We did (I think) a good job of managing message types so theoretically we could put it all into one queue and the application would still function.
Is there a best practice on when to maintain separate queues and when to consolidate in a scenario like this?