TenantOS

Architecture

A control plane holds tenant records, plan entitlements, and usage counters. Job submissions are admitted or rejected against remaining quota. Every mutation appends an audit event. Isolation here is a data-model sketch, not a deployed cell-per-tenant architecture.

Tenant context → entitlement lookup → quota remaining → job admit or reject → usage increment → audit record.

Decisions

• — Keep tenant switching as a global context so every panel reads one selected tenant.
• — Reject jobs that would exceed remaining capacity instead of silently queueing them.
• — Write an audit row for every local action, including rejected jobs.

Trade-offs

• — Shared infrastructure is cheaper and noisy-neighbor risk is real.
• — Hard quota rejects are fair and they surprise tenants who expected burst headroom.
• — Plan changes take effect immediately in this demo; production often needs a billing period boundary.

Failure modes

• — A starter-plan tenant cannot enable SSO even if an operator toggles the control.
• — Job submission fails when API or worker quota is exhausted.
• — Reset restores the seeded tenants and drops demo audit history.

Evaluation

Usage bars, remaining quota, and audit entries are derived from the selected tenant record and the local action log.

Production extensions

Proposed — not implemented in this portfolio.

• — Shard tenant data with row-level security or separate schemas.
• — Meter usage from a billing pipeline rather than in-memory counters.
• — Add hierarchical organizations and delegated admin roles.