Moving single tenant application with queue to multi tenants web application

Question

I need to move a single-tenant (.net core) 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 queues 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

The second choice is by far easier to manage, being purely configuration to spin up new customers (as opposed to infrastructure creation/management). To extrapolate further, your life would be much easier creating a single database and adding something akin to a "customer id" to all your tables/queries. This allows you to segment your application, and make new customers as simple as inserting a row in the database (as opposed to creating a whole new database instance).

Answer 2

A multi tenant implementation means you are stepping into a multi dimension world. IMO, it's very difficult to give a recipe for a multi tenant application without knowing the nature of the business and its factors.

One important item I will look at is the load that each tenant is going to introduce to the application. Generally you wants tenants with similar load to share resources. If one has a load 100 times the others combined then the experience will not be great.

At the same time you want to be able to take a small step and cannot afford implementation based on 10k tenants and serve only to 100. However, you also don't want to throw your application away and write from scratch when your tenants grow to 10k.

As you can see, it's not a simple decision.

I would always think about my next step when designing for my current need. It's important that your design is flexible and extendable, at least for the next phase of your business that you can see.

In your case, it seems like you can see your next step (multiple virtual hosts - basically dedicated resources for tenants) but you know like you don't need that at this point.

My suggestion to you is to design based on multiple virtual host but implement based on single host. That way if down the line it happens that one tenant's load is killing others then at least you can separate that tenant with a relatively smaller effort.