question: how to set up priority? about bus

[adenhertog]

hey @haayman-imagem I realise this is an old issue, but I had a chance for a deep dive of this the other day and wanted to document the results here.

there are two main ways to deal with priorities in a queuing system:

• priority by the type of message (per your goal)
• priority by the metadata of the message (eg customer value ranking)

The approaches for each are quite different. For a message type priority, multiple queues may be used which subscribe to different topics depending on the priority. When fetching messages, messages from the priority queue are read first and if empty then messages in the standard queue are read.

There're a number of issues with this. Firstly most transports don't provide a way to accurately tell if a queue is empty without explicitly reading from it. This library favours long polling of queues as it provides the cheapest cost (for managed queues) and better performance. The only way to truely service this scenario would be to continuously short poll both queues in priority order that could end up being quite costly for things like SQS in a distributed system and also incur a performance hit if the priority queue is constantly empty but having to be called prior to the standard queue being read.

For this type of approach, it's probably better to spin up a separate worker service that only handles high priority messages according to the needs of your app.

For a metadata-based priority system, some transports like RabbitMQ do support publishing messages with a priority that will be read before lower priority messages. It's a very loosely-defined AMQP spec that's in no way prescriptive nor universally supported by all queues.

This is the ideal approach that also supersedes the first approach, but as it is a transport-level feature that's only supported for some transports, it's not something that can be added directly into @node-ts/bus-core. I also want to avoid an abstraction leak of exposing transport-specific features at the application level; however there's probably a good trade-off to be had between exposing these type of useful features at the cost of being tied in to a transport.

tldr - priorities aren't tough, aren't universally supported by all transports. if there's enough 👍 support then this might be implemented by exposing elements of the transport at the app layer.

[adenhertog]

This has come up a couple of times over the past year and has been solved by creating a separate priority service with its own queue. This works well in the case where certain message types need priority over others; but the real case for priority messages is where there's priority across message types based on eg a high value customer etc whose messages need to be processed before others.

The former case, which is the target of this issue, won't be implemented but priority messages is something that may come down later on.