Since lesson 4.1.2, "several offices in one Kladde" has been Q1, at the very top of your quality goals. Since module 4.3, every key has carried a tenant ID, and since lesson 4.7.3 the sign-in admits people from several Entra directories, one per office. One question has remained open, and it is the most expensive architecture decision of this module: How much do the offices share? One Kladde for all, one Kladde per office, or something in between?
This lesson introduces the models, with their consequences for isolation, operations and cost. You build row-level security as a second safeguard, design the control plane that creates, updates and removes offices, and decide the Kladde's model in an ADR. It is built in the final project 4.9.
Tenant and instance
Keep two terms apart in this lesson:
- A tenant is an office: a customer of the Kladde, with its people and its data. In the Kladde it is an Entra directory, recognized by
the
tid(lesson 4.7.3). - An instance (Microsoft also says deployment or stamp) is a set of running infrastructure: a Container Apps environment with its apps and the cluster, a database, a Service Bus namespace, a Key Vault.
How many tenants live on one instance is the tenancy model. For an office to find its instance, every variant with more than one instance
needs a mapping tid → instance. It belongs to the control plane, more on that below.