Five Architecture Decisions Every Multi-Tenant SaaS Makes Early
Tenant isolation, identity, billing, configuration, and observability. Getting these right early saves expensive rewrites later.
Some SaaS decisions are cheap to change later. Others are baked into every table, query, and API. These five belong in the second group, so it is worth making them deliberately.
1. How tenants are isolated
Shared database with a tenant column, schema per tenant, or database per tenant. Shared tables are simplest to operate; separate databases give stronger isolation for regulated customers. Many products start shared and add a dedicated option for enterprise plans. Whatever you choose, enforce tenant scoping in one place rather than in every query.
2. Identity and access
Model users, organizations, and memberships separately from day one. A user who belongs to two organizations should not need two accounts. Plan for roles, invitations, and later SSO without redesigning the data model.
3. Billing as a domain, not a webhook
Plans, entitlements, and usage deserve their own module. Product code should ask "is this organization entitled to feature X?" rather than checking a plan name. That keeps pricing changes out of your feature code.
4. Configuration over customization
Enterprise customers will ask for custom behavior. Feature flags and per-tenant configuration let you say yes without forking the codebase.
5. Observability per tenant
Tag logs, traces, and metrics with the tenant ID. When one customer reports that the product is slow, you want to see their experience, not just the global average.
- Centralize tenant scoping
- Separate users from organizations
- Model entitlements explicitly
- Prefer configuration to forks
- Make every signal tenant-aware
