Multi-tenancy

Required

• Run every background job inside its tenant

  DAT-68

  Put the tenant ID in every job's payload, and make the worker set the tenant context before it touches data. A job without a tenant ID fails at once.

• Delete every copy of a tenant when the contract ends

  DAT-72

  When a customer leaves, return or delete their data in every store within the period your contract states. Backups holding it expire on their normal schedule.

Recommended

• Choose the isolation model before the first customer

  DAT-67

  Write down where each customer's data lives, in shared tables, a schema per tenant or a database per tenant. Record the reason and the tenant count it must reach.

• Keep files and search indexes apart by tenant

  DAT-69

  Store each tenant's files under a path that starts with its tenant ID. Filter every search and vector query by tenant on the server, inside the query.

• Put the tenant on every log line and trace

  DAT-70

  Add the tenant ID as a field to every log entry, trace and metric written while serving a tenant. Never put the tenant's name or data in that field.

• Restore and export one tenant alone

  DAT-71

  Keep a tested script that exports one tenant's data from every store, and one that restores a single tenant from backup without changing other tenants.

• Find and contain noisy neighbours

  DAT-73

  Measure database time per tenant, and give each tenant its own query time limit and job share. Move a tenant that uses more than a quarter of the database time to its own resources.

Optional

• Give each tenant its own encryption key when customers ask to hold it

  DAT-74

  When customers ask to hold their own key, encrypt each tenant's sensitive data with a data key wrapped by a key per tenant. Let a customer's key live in their own key service account.

• Pin each tenant's data to its region

  DAT-75

  When a customer's contract names a region, store the region on the tenant and keep its database rows, files, backups, logs and search indexes there.