In the course of building systems, you’re frequently going to have a single logical system that needs to serve different sets of users or clients. Some examples I’ve run across have been systems that need to segregate data for different partner companies, different regions within the same company, or just flat out different users like online email services do today. You could just deploy completely different installations of your application for the different customers or groups within your company, but that's not likely going to scale very well.

Instead, let's do a deep dive into the idea of multi-tenancy, which roughly speaking is the ability for one deployed system to segregate data between multiple groups of users that we'll call "tenants" from here on out. We can do that either through using separate databases altogether for the different tenants, or we can somehow segregate tenant data within the same database.

As someone who both builds and supports development tooling for multi-tenancy and directly helps customers implement multi-tenancy, I'll do a deep dive on how decisions about multi-tenancy will effect your application's scalability or data security. I'll also show you ways to more easily accommodate multi-tenancy successfully in both web applications and asynchronous messaging throughout the entire application stack.