SaaS architecture: the decisions that are hard to reverse

Multi-tenancy: how customers are separated

A tenant is one customer organization. The main question in SaaS architecture is how far apart tenants' data should sit, since more isolation generally costs more to run.

Shared tables

All tenants share a database and tables, with a tenant ID on each row. It is the cheapest and simplest to run, but it relies on every query being correct.

Separate schemas

One database with a schema per tenant. This gives stronger separation, but changes must be rolled out across every schema.

Separate databases

A database per tenant. This gives the strongest isolation and is easier to explain to enterprise buyers, but costs the most to operate.

Enforce isolation below the application

Relying on every developer to remember a tenant filter is risky. Database row-level security or a single enforced data-access layer gives a second line of defense. Tests should actively try to reach another tenant's data.

Identity and permissions

Model organizations, users and roles from the start, since a person may belong to more than one organization. Using an established identity provider makes it easier to add single sign-on later, which larger customers commonly ask for.

Billing as part of the design

Use a payment provider, and keep your own record of each customer's plan and what it allows. Build for trials, plan changes, failed payments and cancellation. Usage-based pricing also needs reliable metering, which is much easier to design in than to add later.

Background work and integrations

Imports, emails, reports and webhooks should run in background jobs that can be retried, so that slow work never holds up the interface. Rate limits and per-tenant fairness stop one large customer from slowing down everyone else.

Monolith or microservices?

Start with a well-structured monolith in most cases. Microservices solve problems of large teams and uneven scaling, and bring operational costs that a young product rarely needs. Clean internal boundaries keep the option open.

Observability and recovery

Tag logs and metrics by tenant, so you can see who is affected when something goes wrong. Decide how much data you could afford to lose and how long you could be down, then test restoring backups against those targets.