question: how to set up priority?

[haayman-imagem]

I know this is not a forum, but I don't know any other way to ask questions.

I've got a setup with several handlers, like emailHandler and i18nHandler.
The i18nHandler start up by sending a message 'getTranslations' to fetch all available translations. This handler has a method getTranslator() that returns a Promise to a translator that gets resolved after all translations are received

My emailHandler calls await getTranslator() before doing it's job.

I noticed this setup doesn't work when I start the entire apps and there are still some email messages in the dead-letter queue. The emailHandler fires up, waits for the getTranslator(), but apparently now there's a deadlock because the messages for fetching or receiving the translations get stuck in traffic?

Is there a way to set it up so the 'getTranslations' and the 'fetchedTranslations' have priority?

[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.