Took me a couple of reads to understand what you're saying. That's a very elegant solution and one that indeed would ensure consistency with only the occasional "wasted" sleep.

Your final point about locks and consistency does give me some slight pause. Due to the speed of messages coming in I can see the possibility of collisions or deadlocks and while fairly small may be enough to consider going to the simpler approach of just creating additional BPLs we're currently using.

In any case, thank you very much for the guidance.

The change would mean that the number of processes could be increased programatically and while a production is running.

If the processed was stopped, queues drained and the pool size increased we'd then be able to have more processes running if we'd noticed a spike in messages (or wanted to increase for future). This would be easier than adding new BPLs into the production as it would only require a single setting change.

Thanks for the reply.

3 keys was only as an example :-), it could be up to n for the number of threads we'd create.

We'd be using an MRN, as we only require that messages for that patient are in order.

So MRN 123 would go to thread 123 mod n always
MRN 456 would go to thread 456 mod n always
etc.

Does that make the question any clearer?