Architecture guidelines for using NServiceBus for a Customer Ticketing System

This is a very broad question related to a Customer Queue Management System. I would like to know your opinion in terms of using NServiceBus. Brief set of features expected from the system is below.

  1. Users request a ticket in a selected queue (technical/customer support) via mobile or web - REST API
  2. Issued tickets need to be saved reliably in some storage
    a. Technical support queue has [1,2,3,4,5] issued tickets in order
    b. Customer support queue has similar queue
  3. Alerting service about the status of a queue which user is interested in (ex:- On my way to a business to get some technical support, I request a ticket via mobile. As long as the mobile app is running I get real-time update about the status of my queue)
  4. Queue Agent - The individual who is responsible in serving each queue calls tickets
    a. Agent may direct the customer to another service (from customer service to tech support queue)
  5. Routing Service - Handles routing services between queues (At all queue changes relevant customers/agents keep informed)
  6. Service Monitoring - Which measures key statistics at certain points and stores for reporting
  7. Reporting - just that….
  8. Other usual blah blah

This will be a multi-tenant solution. So each message going back and forth will always be tied to a tenant which I think is not relevant to NServiceBus.

Also, different businesses may handle their customer service journey differently. So ideally these user journeys must be pluggable for different tenants.

Now this whole thing is a user journey which is long running. So is it correct to say (if I apply this to NServiceBus related usage) that this is a saga?

What would be the best approach in tackling these scenarios in terms of NServiceBus? Some insights will help me get going with the rest.

@modithak_K welcome to the Particular discussion group.

It is relevant as it requires that the selected NServiceBus persister supports multi-tenancy. SqlPersistence is one of them:

This makes things a little more complex, it really depends on the kind of customization your looking for, and who is in charge of this customization.

Sagas are a perfect choice for the scenario you described. Customization aside, that as said complicates things a little bit.

I would define a saga type for each “support queue” so that each queue can have a different business process. And then model messages and behaviors to mimic the support process.

If you are interested we can help with a proof of concept.