mercredi 22 janvier 2020

Rabbit mq message broker in multi-tenants web application

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.

Aucun commentaire:

Enregistrer un commentaire