Multi-Tenancy

When a product serves several organizations, the same person may have different permissions in each one. Suppose the bookstore adds purchasing workspaces, and Alice manages book purchases for Northstar Labs but can only view purchases for Cedar School. After switching to Cedar School in the interface, she must no longer be able to edit using her Northstar authority. A valid login and a familiar resource ID cannot decide that boundary on their own.

Multi-tenancy lets one product serve multiple customer groups while keeping their data and authority appropriately separated.

This chapter explains tenant selection, membership, storage isolation, and how tenant context must remain consistent across requests, caches, jobs, and administrative operations.

The examples use a fictional organizational purchasing API over HTTPS. Each organization is a tenant. Purchase lists belong to an organization and are separate from personal reading lists. The API uses organization IDs in paths, verifies current membership, and shares database tables with an explicit tenant key. These are application choices, not universal HTTP conventions.