# Pattern: Tenant Data Partitioning

Status: seed
Readiness target: RL3 production
Primary owners: product repos, NetKingdom
Genesis family: Tenant isolation

## Problem

Tenant data can leak when storage, query, object, or cache access does
not enforce tenant partition boundaries.

## Context

Use this pattern for shared databases, object storage, search indexes,
caches, queues, analytics stores, and backup/export paths.

## Forces

- Shared data stores improve efficiency.
- Every data access must include trusted tenant scope.
- Query bugs can bypass application-level checks.
- Backups and exports need the same tenant boundary as live systems.

## Solution

Partition data by tenant at the storage or query layer and require
tenant-scoped authorization before access. Use schema, prefix, row-level
security, bucket/prefix policy, or dedicated stores according to risk.

## Verification

- Cross-tenant query and object access tests fail.
- Background jobs and exports carry tenant context.
- Backups, search, and caches preserve tenant partitioning.
- Audit records identify tenant, object, and actor.

## Related Patterns

- Tenant Context Propagation.
- Object-Level Authorization Check.
- Key-per-Tenant.
- STS Credential Vending.