Moving single tenant application with queue to multi tenants web application

Question

I need to move a single-tenant web application to a multi-tenant (about 100 tenants) web application. Tenants are going to share the same application but each tenant is going to have its own database (database for tenants) I have already planned to move my in-process application cache to a shared distribuited cache identifing cache items by adding a prefix (the tenant-id) to the cache iteme keys (prepended-tenant pattern).

Application also rely on RabitMQ to implement async processes. Actualy I don't have many queues, just a dozen and few exchanges but i suppose the number of queue and exchange is going to increase in the future.

Now Im confused about the best architectural pattern for queues when moving toward a multi-tenant architecture.

Choices:

1) Multiple virtual host (one per tenant) with same topology replicated per virtual host

2) Single virtual hoost with same queues, exhanges, ecc shared among tenants.

The first choice seems to be more complicated to manage as I shoud keep syncronized the topology for every virtual host (suppose 100 tenants means 100 vhost) The second choice seams the easier one, I only need to pass in the context of every messages sent to queues the tenant-identifier so the consumer knows who is the owner of the message and what to do with it.

I would know some opinions mainly with regards to the second choice as it seems to me more affordable.

Answer 1

First choice is better for security and independence between tenants, like the choice about database.But you have to build tools to handle it. Failure of one queue, don't expose failure to other tenants.

First is not simple technically, but have functionals advantages :

• limited failure
• independence between tenants/confidentiality, eg: data cannot be exposed to wrong tenant
• you keeps options open

Second is simple technically, but have technicals advantages :

• very simple to maintain

When you go to multi-tenant system, keep in mind that customers will prefer to not use system that mutualize data.That could be catastrophic for yours customers and your company if inappropriate data come at the wrong place.

Answer 2

I would try to limit how far the concept of tenancy spreads throughout the application design. Many (micro)services can be designed without the need to have a tenantID. They may not need to know this information or whatever information is needed for them to process the task can be included in the message.

For example a PDF conversion service may not need any tenant information, or it may need the company name which you can include in the message so the service does not need to have the knowledge how to retrieve this information.

In case of OAuth, the tenant ID can travel in the user token.