Support queue per handler/saga

[ramonsmits]

Describe the feature.

Is your feature related to a problem? Please describe.

NServiceBus had the concept of "endpoint" and "handlers" (and sagas, sagas are a type of handler). Endpoints host one or more handlers. Endpoints are represented by queues.

When an endpoint hosts multiple handlers all share the same "endpoint" queue.

This can be problematic in several ways:

• Subscriptions map to "endpoints" and not to "handlers"
• Moving handlers to another host has a lot of manual overhead
• Performance issues on a handler cause issues for all handlers because they are sharing the same queue
• Infrastructure monitoring is more difficult as you need to inspect the actual message to discover for what handler the message is
• Retrying messages is more complex. You can't easily move messages for a given handler
• Impossible to do fine grained access control

Many of these issues will not immediately surface when you start developing a system but once a system gets more mature suddenly these can become problematic.

Describe the requested feature

Map (ideally by default) handlers and sagas to a queue. Optionally grouping handlers/sagas could be supported.

This mitigates all the issues listed above.

If this is the default topology it gives users way more freedom and flexibility in:

• deployment
• access control
• monitoring
• performance

Additional Context

No response

[bbrandt]

This would be amazing. We have code we have split out and deployed as separate services only for the purpose of getting them onto their own queue, to avoid a problem similar to the "noisy neighbor" problem you have in multitenant sharing situations.

If we are already not guaranteeing ordering of messages, I don't see what the advantage would be to have different handlers on the same queue as we have right now in NSB.

[ramonsmits]

Another benefit of this model is that the concurrency can be controlled per queue. For example, setting the concurrency to 1 would result in sequential message processing.

With the endpoint concept setting the concurrency to 1 this will impact all handlers/sagas. As concurrency is controlled by endpoint, it could happen that handlers are idle while message are in the queue but cannot be processing due to the concurrency limit.

To mitigate this, such handlers would currently need to be extracted to separate endpoints