I am quite new on Azure Bus Service technology, and I am doing my first application that integrates two systems leveraging it.
I am struggling on deciding upon my queue pattern.
One of the systems will be triggering the events based on what is happening on some tables and on demand processes (create,update,send,xxx...) and that will be processed asynchronously by the Bus functions.
The app is expected to have high volume of work, so I am considering on those patterns, probably are better solutions so please feel free to point them out:
1 process - 1 queue. If there is a for instance "Duplicate and send" process, there will be a queue specifically for that process and 1 function worker to process it.
1 table - 1 queue. For each table, there is 1 queue,that holds all related to that table. This will be processed by an orchestration function that will distribute the requests.
¿Which is the common or best practice pattern? Are there any other options?
I have been reading the whole internet and many Githubs but I am just get more confused.
The scenario looks suited for an queue based architecture where you need a messaging backbone for your messages and the other end processing it updating a table. . You should consider leveraging Service Bus Queues (Enterprise Grade Messaging Services) for your message storage and transport and Azure functions or Azure Logic Apps to process these messages and update the table. Queues are resilient modes of communication as compared to other options. I am also attaching a few links where you will get further insights on these alternatives/options.