Multi-Tenant SaaS Architecture Diagram: Silo, Pool and Bridge Models

Draw a multi-tenant SaaS product the way most teams draw any system, and it looks exactly like a single-tenant one: a gateway, some services, a database. The most important property of the system, which customer's data can end up where, is nowhere on the page. Yet that property drives the hardest decisions: how tenants are isolated, how big customers are served, how onboarding works and what a noisy neighbor can break.

This guide shows how to make multi-tenancy visible on an architecture diagram: the vocabulary, what to show, the silo, pool and bridge models, and an example with both shared and dedicated resources.

The vocabulary

The terms below are common in SaaS architecture writing, including AWS's SaaS guidance:

• Tenant. A customer organization, with its own users and data.
• Control plane. Services that manage tenants rather than serve the product: onboarding, the tenant registry, identity, metering and billing.
• Application plane. The product itself: the services and data stores tenants use every day.
• Tenant context. The tenant id that travels with each request, usually as a claim in the access token.
• Silo. Resources dedicated to one tenant, such as a separate database or a full stack.
• Pool. Resources shared by many tenants, separated by policy and by tenant id.
• Bridge. A mix of the two: for example shared compute with dedicated databases for some tenants.

What the diagram has to show

1. Where tenant context comes from. The identity provider and the token claim that carries the tenant id.
2. Where isolation is enforced. Not "in the code", but at a specific place: a row-level security policy, a per-tenant schema, a separate database, an IAM policy.
3. Which resources are shared and which are dedicated. Label each data store and service as pooled or siloed.
4. How a request finds its resources. The routing or lookup that sends a tenant to the right database or stack.
5. How tenants are created. The onboarding flow that writes the registry and provisions any dedicated resources.

Silo, pool and bridge

Model	What is shared	Strengths	Costs
Silo	Nothing in the application plane	Strong isolation, per-tenant tuning, simpler compliance answers	Higher cost per tenant, more deployments to run
Pool	Compute and data, separated by tenant id	Low cost per tenant, one deployment	Isolation depends on every query and policy; noisy neighbors
Bridge	Some layers shared, some dedicated	Spend isolation where it matters	Two paths to build, test and draw

Many products start pooled and move their largest or most regulated customers to silos later, which turns the system into a bridge. The diagram should make that split obvious.

The example: pooled tenants and one enterprise silo

A B2B analytics product has hundreds of standard tenants and one enterprise customer, Globex, that requires its own database:

• Users sign in through a tenant-aware identity provider. Their access token carries tenant_id.
• The API gateway validates the token and passes the tenant context to the analytics API.
• The analytics API looks up the tenant's tier and database in the tenant registry.
• Standard tenants share a pooled PostgreSQL database, where row-level security filters every query by tenant_id.
• Globex gets a dedicated database, provisioned by the onboarding service when the tenant was created.

Two frames separate the control plane from the application plane, and the labels on the data stores say which isolation model applies. A reviewer can now ask the right questions: what happens if the registry is down, and who can change a tenant's tier?

Rules for multi-tenant diagrams

Draw tiers, not tenants

Never draw one box per customer. Draw one path per tier or deployment model, and name an example tenant if it helps, as with Globex above.

Label the tenant context on edges

Write how the tenant is identified on each hop: JWT tenant_id, header X-Tenant-Id set by the gateway, tenant_id in the message. Background jobs and event consumers need tenant context too, and they are where it most often goes missing.

Put the enforcement point on the diagram

"Isolated by tenant id" is a promise; a row-level security policy, a schema per tenant or a separate account is a mechanism. Label the mechanism on the data store or add a Policy node next to it.

Show per-tenant limits

Rate limits, quotas and concurrency limits per tenant are how a pooled system protects tenants from each other. Note them at the gateway and on the services that enforce them.

Keep metering and billing in the control plane

Usage events per tenant feed metering and billing. Draw them in the control plane, so the application plane stays focused on serving requests.

Common mistakes

• No control plane. Onboarding, the tenant registry and identity are core architecture, not admin tooling.
• Isolation by convention. A note that says "every query filters by tenant" is not a control. Show the policy that enforces it.
• Invisible routing. If some tenants use different resources, draw the lookup that decides it.
• Forgotten async paths. Queues, scheduled jobs and analytics exports that lose the tenant id are a classic source of leaks.
• One giant diagram. Keep data residency (regions), deployment and the logical view on separate diagrams.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add two Core Frame nodes, Control plane and Application plane.
3. Add two Core Box nodes for the standard and Globex users, a Security pack Identity Provider, a Cloud pack API Gateway, and C4 Model Container nodes for the onboarding service and the analytics API.
4. Add Data pack Postgres nodes for the tenant registry, the pooled database and the dedicated one, with the isolation model in the label.
5. Label edges with the tenant context and make the provisioning edge dashed.

The example uses 11 diagram nodes, within the Free plan. For the cloud and network layer underneath, see the AWS VPC diagram and the cloud use case page.

FAQ

Which isolation model should I choose? Start from your customers' requirements and your cost per tenant. Pool is cheapest to run, silo is easiest to explain to a security reviewer, and bridge lets you offer both. Write the reason on the diagram.

How do I show hundreds of tenants? You don't. Show each tier or deployment model once, and keep the list of tenants in the registry where it belongs.

Does each tenant need its own diagram? No. One diagram per architecture, with the tiers on it. A siloed enterprise tenant might get its own deployment diagram if it runs in a separate account or region.

How do I show data residency? With region frames on a separate deployment diagram, each holding the stacks or databases for the tenants that must stay there.

Where do per-tenant encryption keys go? Next to the data stores they protect, as a Security pack node or a note, with the key management service that holds them.

Start free — one seat, no credit card.