When you are architecting a multi-tenant SaaS platform
Multi-tenancy is a set of decisions that are almost free to make on day one and almost impossible to revisit on day four hundred. The expensive ones are rarely the ones that got discussed.
The situation
The product works and is growing. The architecture that got it here was assembled a decision at a time, and nobody has looked at the whole of it since the shape changed.
The characteristic SaaS failures are structural rather than dramatic: one shared component that every tenant depends on, a database where a single heavy tenant degrades everyone else, and a cost curve that turns out to be steeper than the revenue curve.
None of those show up in a load test of a single request path. They show up when the design is looked at as a whole, against the load it will actually carry, which is a modelling exercise rather than a testing one.
You are here if
- One customer’s usage pattern can slow the product down for everybody.
- You cannot say what happens to any given tenant if a single service fails.
- Infrastructure cost per tenant is unknown or is rising.
- Scaling happens by somebody noticing and reacting.
How the work gets done
Start from the pack, then argue with it
Applying the SaaS pack switches the workload profile and sets the six non-functional targets below. Treat them as a starting position rather than a recommendation — the value is that they are explicit and therefore arguable, where the numbers in your head are neither.
The targets you disagree with are the useful ones. Changing 99.9% to 99.95% is a conversation with real consequences for the design, and it is better had now than during an incident review.
Simulate ▸ Industry PackSimulate ▸ Workload ProfileSimulate ▸ Guided Setup Wizard
Find the components every tenant shares
The single point of failure check is the one that matters most in multi-tenancy, because a shared component failing is not a degraded experience for some customers — it is an outage for all of them.
Bottleneck detection covers the quieter version of the same problem: the component that does not fail but saturates, which is how the noisy-neighbour effect actually arrives.
Simulate ▸ Rule EvaluationSimulate ▸ Bottleneck DetectionSimulate ▸ Resilience Score
Make the cost curve visible before it is a problem
Model the cost against the architecture rather than against last month’s invoice, so the question "what does the next thousand tenants cost" has an answer that comes from the design.
Sensitivity analysis is the more useful half: it says which assumption the cost is fragile to, which is what you want to know before committing to a shape.
Arch ▸ BudgetSimulate ▸ Sensitivity Analysis
Record the isolation decision where it can be found
Whether tenants share a database, a schema or an instance is the decision that everything else inherits, and it is the one most likely to be relitigated by someone who was not there. Record it with the reasoning, against the components it applies to.
Arch ▸ RepositoryArch ▸ Tech Debt Report
What the SaaS Platform pack sets
Multi-tenant cloud-delivered software. Prioritises uptime, low latency, and predictable cost. Applying the pack switches the workload profile and sets these six targets on the model. It does not change the design and it does not enable any industry-specific check — the targets are what the design is then evaluated against.
| Workload profile | Steady SaaS — Consistent load typical of B2B SaaS — low burst, predictable concurrency. |
|---|---|
| Availability target | 99.9% |
| Latency target (p95) | 200 ms |
| Throughput target | 1,000 requests/sec |
| Cost target | $20,000 / month |
| Recovery time objective | 15 minutes |
| Recovery point objective | 60 seconds |
The policies this pack highlights
- No Public Database Exposure — Databases must not be directly accessible from the public internet without a proxy or API gateway.
- Availability SLA ≥ 99.9% — System composite availability must meet or exceed the organisation baseline of 99.9%.
- Monthly Cost Within Budget — Estimated monthly cost must not exceed $50,000 without an approved exception.
The risks it names for this industry
These are prompts to work through against your own design, not findings. The pack lists them; nothing evaluates them for you.
- Shared infrastructure SPOF affecting all tenants
- Noisy-neighbour effects on multi-tenant databases
- Scaling lag during viral growth spikes
- Cost runaway during unexpected traffic surges
What is still yours to check
The simulation evaluates the architecture itself — single point of failure, deep synchronous dependency chain, shared database across services, connection pool saturation risk, no autoscaling configured and excessive retry configuration — against the targets above, and the policy checks run on every design. The concerns below are specific to saas platform and nothing in the product evaluates them. The pack names them so they stay on your list; the review is a human one.
- Observability coverage — per-tenant dashboards, alerting and traces
- Tenant isolation and quota enforcement in shared data stores
- Cost guardrails and budget alerting for unplanned traffic surges
What you end up holding
- A stated set of non-functional targets that the team has actually argued about.
- A list of the components every tenant depends on, and what happens when each fails.
- A cost model attached to the architecture, and the assumption it is most sensitive to.
Not this, if
- You are single-tenant or on-premise per customer. The tenancy questions that make this worth doing do not arise.
- You want load testing against the running system. Simulation reasons about a model; it does not generate traffic.
- The product is pre-launch with no usage data. Model the design, but treat every throughput number as a guess until real traffic exists.