Tenancy models: silo, pool and bridge

A tenancy model decides how much of your stack each customer, or tenant, gets to itself. In a silo, a tenant gets dedicated resources. In a pool, tenants share resources, and the tenant’s identity travels with every request and sits on every row. A bridge mixes the two, layer by layer and service by service. The choice sets your cost per tenant, your blast radius, your release speed, and which customers you can sell to.

Picture it first: bungalows, a hostel and a housing society

Think about where people live in a big Indian city.

• Independent bungalows. Each family has its own plot, water tank and gate. A neighbour’s party never floods your kitchen, but every family pays for a whole plot, and the plumber visits each house separately.
• A paying-guest hostel. Everyone shares the kitchen and the wiring. It is the cheapest bed per person and one repair fixes the pipes for all, but one noisy resident keeps the floor awake, and one fire alarm empties the building.
• A flat in a housing society. Your flat is yours alone; the lift, the gate and the water tank are shared.
• A township of identical towers. A power cut in Tower C leaves Towers A and B lit, and when a tower fills up, newcomers move into a new one.

Map it back. Bungalows are silos, the hostel is a pool, the housing society is a bridge, and the township is a fleet of deployment stamps. The one office that handles admissions and bills for everyone is your control plane.

Silo, pool and bridge

Silo means a tenant gets dedicated resources. That can be the whole stack or a single resource, such as a database of its own. Infrastructure enforces the boundary (separate accounts, networks and credentials), so a bug in your code cannot easily reach another tenant’s data. AWS’s SaaS Lens adds a condition: a silo still shares onboarding, identity and operations with every other tenant. That is the line between SaaS and managed hosting, where each customer runs its own version.

Pool means tenants share compute, storage, queues and caches. Nothing in the infrastructure tells tenants apart, so the application must: each request resolves a tenant ID, usually from the user’s token (see routing requests to tenants), and every call, row, object key, cache key, message and log line carries it. Capacity grows with the total load, not the number of tenants.

Bridge means some parts are siloed and others pooled. AWS uses the word to admit that real systems are rarely pure. A common shape is a shared web and app tier in front of a database per tenant.

The band at the bottom is easy to forget. Whatever the data plane looks like, the control plane is one system: one sign-up flow, one identity service, one billing pipeline, one release train. AWS’s whitepaper is blunt that siloed stacks must all run the same version with no one-off variations; otherwise you are hosting 50 slightly different products.

Decide per layer and per service

The useful question is not “is our system silo or pool?” but “for this layer of this service, do tenants share?” Layers carry very different risks:

• The web and API tier is stateless and cheap to scale. Sharing it rarely worries anyone.
• The app tier runs your code. Sharing it is fine until it runs customers’ code, such as scripts or plugins, which deserves a sandbox per tenant.
• The data tier holds what regulators care about, and it is where one tenant’s heavy query slows everybody else. It is the usual candidate for siloing.

AWS’s SaaS Lens agrees: a service’s regulatory profile and noisy-neighbour behaviour push it towards silo, while agility, access patterns and cost push it towards pool. The next figure shows a B2B commerce SaaS, the kind that runs storefronts for thousands of small Indian brands, choosing separately for every service.

The two middle columns are the interesting ones. Documents keep shared code but give each tenant its own bucket and encryption key, which makes “export everything” and “delete everything” trivial. Integrations do the reverse: customer scripts run in a sandbox per tenant, while their small config rows share one table.

The data layer has a finer menu of its own (database per tenant, schema per tenant, or shared tables with a tenant_id column); see multi-tenant data.

Shopify is a large real-world bridge. In 2016 it split its platform into pods: groups of shops on fully isolated datastores (a MySQL shard plus Redis and Memcached) behind shared app servers, job workers and load balancers. Every request or job talks to exactly one pod, chosen by a routing layer in the load balancers, so a pod failure stays inside that pod.

Same spectrum, different names

AWS and Microsoft use different words for the same ideas. Azure treats isolation as a continuum from “shared nothing” to “shared everything”, with each component at its own point. The vocabularies line up like this:

Azure’s vertical partitioning also covers regional copies with each tenant mapped to one, which is stamps by another name. Both vendors land in the same place: tenants are not deployments. You keep a map from each tenant to the deployment holding its data, and you can change it later.

What each model costs

Cost is where the models differ most, and the shape matters more than the prices. Take an illustrative B2B helpdesk SaaS with 2,000 tenants, most of them small. Every number below is a round, assumed monthly cost, not a price list.

• Full silo. The smallest production stack needs two app instances, a small managed database with a standby, a load balancer, backups and monitoring. Assume that floor is $350 a month, whether the tenant sends 10 requests a day or 10 a second. For 2,000 tenants: 2,000 × $350 = $700,000 a month.
• Full pool. One fleet sized for the combined peak. Assume a fixed floor of $3,000 (a database pair with room to grow, the cluster, observability) plus about $4.50 of capacity per small tenant. For 2,000 tenants: $3,000 + 2,000 × $4.50 = $12,000 a month, or $6 per tenant.

That is roughly 58 times cheaper per tenant ($350 ÷ $6). The reason is idle capacity: a silo keeps two of everything running for a tenant that is busy a few hours a day, while a pool lets one tenant’s quiet hours absorb another’s busy ones. As Azure’s guidance puts it, 100 single-tenant deployments probably cost 100 times one.

The pool is not cheaper at every size. It wins only when $3,000 ÷ N + $4.50 is below $350, which means N above 3,000 ÷ 345.5 ≈ 9 tenants. Below that, a few silos cost less than building a platform.

Two more data points. Split the pool into 8 stamps of 250 tenants, each duplicating about $750 of floor (its own database standby, load balancer and monitoring): $12,000 + 8 × $750 = $18,000, or $9 per tenant. Or run a tiered mix: 1,980 standard tenants in those stamps (1,980 ÷ 250 = 7.9, still 8) for about $18,000, plus 20 enterprise silos sized for their heavier load at about $1,500 each. That is $18,000 + $30,000 = $48,000 a month, and the enterprise price must cover its $1,500.

The bill hides the pool’s real cost: engineering. You must build isolation into code, per-tenant limits and metering; a silo gets most of that from the infrastructure. See cost-aware design for weighing the two.

The other trade-offs, in numbers

Blast radius. A bad deploy in a full pool reaches 100% of tenants; in a full silo, the one tenant you deployed to first. AWS’s cell guidance gives the arithmetic in between: with 10 cells, a failure in one leaves 90% of requests untouched.

Noisy neighbours. In a pool, one tenant’s month-end report can eat the shared database’s CPU, and everyone’s p99 rises. A silo removes the problem by construction; a pool needs per-tenant quotas, fair scheduling and a way to move a heavy tenant out. See noisy neighbours and fairness and the noisy neighbour anti-pattern.

Onboarding. Joining a pool is a row in the tenant catalog plus an admin user, done before the welcome email is sent. Joining a silo runs a pipeline that creates a network, a database, DNS records and certificates: minutes at best, it can fail halfway, and AWS notes it may mean raising account limits.

Shipping a release. Suppose you run 500 silos, each stack takes about 12 minutes to deploy, and you dare run 25 at once. That is 500 ÷ 25 = 20 waves × 12 minutes = 4 hours per release, and every schema migration runs 500 times. If 0.5% of stack deploys fail, each release leaves about 2.5 broken stacks to fix by hand. A pool ships once, behind a canary.

Customisation. Siloed tenants can get their own sizing, maintenance window or update ring. The trap is forking code for one customer: AWS’s guidance allows no one-off variation in a silo, so turn a genuine need into configuration any tenant could switch on.

Compliance and residency. “Our data sits in its own database, encrypted with our key, in an Indian region” is easy to prove with a silo and hard to sell from a pool. A bank or a hospital chain may insist on it, and AWS lists support for strict compliance models as a core silo strength.

Cost attribution. A silo’s cost is its cloud bill, filtered by a tag; AWS counts that as a silo advantage. In a pool you must meter requests, CPU time and bytes per tenant, then share out the common costs.

Tiering: pool the many, silo the few

Most SaaS businesses have a long tail of small tenants and a handful of large ones, so the design follows the price list. Free and standard tenants share a pool, which keeps the free tier affordable. Enterprise tenants can buy a silo for isolation, guaranteed performance or a contract clause. AWS’s whitepaper describes exactly this: basic-tier tenants in a full-stack pool, premium tenants in full-stack silos, every stack on the same version.

The hard part is the arrow between tiers. When a pooled tenant upgrades, its data must move into a fresh silo without a long outage. Azure’s tenant life cycle guide lists other reasons you will move tenants anyway: rebalancing load, a request for a dedicated data store, and region moves after an acquisition or a change in law.

1. Provision Acme’s silo from the same template and release as the pool.
2. Bulk-copy Acme’s data: every row where tenant_id = 'acme', plus files and search documents.
3. Stream changes that land in the pool meanwhile, using change data capture, until the lag is a few seconds.
4. Freeze and flip. Block Acme’s writes for a moment, drain the last changes, and update Acme’s route.
5. Verify and clean up. Compare counts and checksums, keep the old copy for a rollback window, then delete it from the pool.

Shopify uses the same loop to rebalance shops between pods: copy a shop’s rows in batches while tailing the MySQL binary log for its changes, take a per-shop write lock at cutover (failing the move if the lock doesn’t come in time), update the routing table, and prune the stale copy.

What makes tenant moves hard:

• Data is scattered across tables, object storage, search indexes, caches, in-flight messages and backups. Anything not tagged with tenant_id cannot be found.
• Writes never stop, so you need copy-plus-tail and a short freeze, not a dump and restore.
• Every pointer must flip together. Routers, cached tenant maps, scheduled jobs and webhooks must all switch, or some writes land in the old home.
• IDs must be unique across homes. Per-database auto-increment IDs collide when a tenant moves back into a pool on a downgrade, so use globally unique IDs.
• Keys and network identity change: customer-managed keys, IP allow-lists and certificates.

Deployment stamps: pooling at scale

A single pool has limits. Its database runs out of headroom, cloud quotas bite, and every deploy is a bet on 100% of your tenants. The answer is not to silo everyone but to run many identical pools, each holding a bounded number of tenants. Azure calls each copy a deployment stamp (or scale unit); AWS calls it a cell. A thin router maps each tenant to its stamp, and a control plane creates stamps and moves tenants. The full pattern is in cell-based architecture: deployment stamps and geodes; here is how it fits tenancy.

Stamps sit between the extremes on every axis:

• Cost stays close to the pool’s ($9 against $6 per tenant in the example) because each stamp duplicates only its floor. AWS notes that cells need not add hardware at all: the same 30 hosts can be regrouped into cells.
• Blast radius shrinks to one stamp, about a quarter of tenants in the figure above. Releases roll out stamp by stamp, so a bad build meets 250 tenants before it meets 920.
• Growth is linear and boring. Pick a capacity proxy such as tenants per stamp, fill a stamp, close it, and deploy the next from the same template. Azure advises at least two stamps from the start, so no code quietly assumes there is only one.
• Placement becomes a lever: a regional stamp for data residency, a dedicated stamp for a whale, a slower update ring for cautious customers.

You pay in moving parts: a router every request depends on, reporting that must gather from every stamp, and moves between stamps, which Azure calls out as hard. Stamps also drift apart in load: Shopify saw almost a fourfold gap between its least- and most-used shards, and simulated moves narrowed it to about twofold.

Silo, pool, bridge or stamps?

How to pick

Ask these in order, about groups of tenants and about layers, not the whole company:

Signals that sharpen each answer:

• Compliance overrides cost, but usually for a few tenants, not all.
• Tenant count and size distribution. AWS’s isolation paper notes that 20 siloed accounts may be manageable while a thousand starts to hurt. Thousands of small tenants with a few whales means a pool plus somewhere to put the whales.
• Price tier. A tenant paying less than the silo floor must be pooled, so free tiers always are.
• Team size. Every silo is a production system to patch, watch and restore; a team of five cannot run 500 without complete automation.

Going deeper: where each extreme breaks

The silo ops tax at 1,000 tenants

At 1,000 silos you run 1,000 databases to patch, upgrade, back up and restore-test, plus 1,000 sets of alarms, and per-account cloud quotas start to bind. “How many active users do we have?” becomes a fan-out query. Worst is drift: one silo’s migration fails and stays behind “just for now”, a customer gets a small change on their stack, and within a year you host many products. The defences: ruthless automation, one template, and moving small tenants back into a pool.

The whale in the pool

The opposite failure is one tenant growing until it dominates the pool, say 30% of all queries. A Big Billion Days-style sale on its storefront saturates the shared database, and 1,999 other tenants feel it. Shopify’s shard-balancing write-up uses a similar example: two high-traffic merchants on one pod with flash sales on the same day. Rate limits and per-tenant quotas buy time; the lasting fix is to move the whale to a stamp or silo of its own. Move it early, because copy time grows with the tenant’s size.

Isolation inside the pool is not optional

AWS’s whitepaper makes a sharp point: an authenticated, authorised user is not the same as an isolated tenant. In a pool, isolation comes from tenant context resolved once from a signed token and enforced at every layer: tenant-scoped credentials for data access, row-level security in the database as a backstop, tenant-prefixed cache and object keys, and tests that try to read another tenant’s data. Multi-tenancy and isolation and multi-tenant data teach those mechanisms.

A silo should be a pool of one

The cleanest designs run identical code everywhere and treat a silo as a pool that holds one tenant. Tenant context is still resolved and checked; the router just maps that tenant to a deployment of its own. The tenancy model becomes a placement decision made by the control plane, not a fork in the code, and upgrades, downgrades, residency moves and whale evictions become one operation: move a tenant between deployments.

Cheat sheet

How to say it in the interview

“A tenancy model is how much of the stack each tenant gets to itself, and I’d decide it per layer and per service. Here I’d pool the web and app tiers with a tenant ID on every request and row, enforced by tenant-scoped credentials and row-level security. Free and standard tenants share stamps of a few hundred tenants each, so a bad deploy or a hot tenant hits one stamp, not everyone. Enterprise or regulated tenants can buy a silo built from the same template on the same release. A tenant catalog maps tenants to deployments, so an upgrade is an online move: copy, stream changes, flip the route.”

Is a stack per tenant still SaaS? Yes, if it is operated as one product: shared onboarding, identity, billing and metrics, with every stack on the same version. Different versions or one-off changes per customer make it managed hosting.

How do you move a pooled tenant into its own silo? Provision the silo from the same template, bulk-copy the tenant’s rows and files by tenant_id, tail changes until lag is seconds, briefly block its writes and flip its route. Verify, then delete the old copy after a rollback window.

A whale tenant is slowing everyone in the pool. What do you do? Short term, per-tenant rate limits and quotas so it can’t starve others. Long term, move it to a dedicated stamp or silo, priced to pay for itself.

How do you know what a pooled tenant costs? Meter it: tag every request and job with the tenant ID, record CPU time, storage and I/O per tenant, and share out common costs by usage. In a silo, the tagged cloud bill does this for you.

When do you add a second stamp? When the first nears a capacity proxy such as tenants per stamp or database CPU, or one failure domain is too big a risk. Ideally run two from day one, so nothing assumes a single stamp.

Where to go next

• What is a tenant?: what counts as a tenant before you house one.
• Control plane vs data plane: the shared layer that places and moves tenants.
• Routing requests to tenants: resolving tenant context and finding its deployment.
• Multi-tenant data: database per tenant, schema per tenant or shared tables.
• Noisy neighbours and fairness: quotas and fair scheduling that keep a pool healthy.
• Metering and usage-based billing: cost and usage per tenant in shared infrastructure.
• Multi-tenancy and isolation: tenant-scoped credentials, row-level security, leak tests.
• Cell-based architecture: deployment stamps and geodes: the full stamp pattern.
• Design a multi-tenant SaaS platform: all of this in one design.

References and further reading

1. AWS Well-Architected SaaS Lens: Silo, pool, and bridge modelsdocs.aws.amazon.comThe three definitions, why a silo still shares onboarding and operations, and why regulation and noisy neighbours push individual services towards silo.
2. AWS SaaS Architecture Fundamentals: Full stack silo and pooldocs.aws.amazon.comBasic-tier tenants in a full-stack pool beside premium tenants in full-stack silos, all on the same version with no one-off customisation.
3. AWS SaaS Architecture Fundamentals: Tenant isolationdocs.aws.amazon.comWhy authentication and authorisation are not tenant isolation, and how isolation ranges from whole stacks to fine-grained policies on pooled items.
4. AWS SaaS Tenant Isolation Strategies: Silo isolationdocs.aws.amazon.comSilo pros and cons: compliance, no noisy neighbours, easy cost tracking, small blast radius, against cost, agility, onboarding and the 20-versus-1,000-tenant operations problem.
5. Azure Architecture Center: Tenancy models for a multitenant solutionlearn.microsoft.comIsolation as a continuum; automated single-tenant, fully multitenant, vertically and horizontally partitioned deployments; tenants versus deployments (stamps).
6. Azure Architecture Center: Deployment Stamps patternlearn.microsoft.comStamps serving a set number of tenants, deploying at least two, routing, rings, blast radius, and why moving tenants between stamps is hard.
7. Azure Architecture Center: Tenant life cycle considerationslearn.microsoft.comReasons to move a tenant between infrastructure: rebalancing, tier upgrades, dedicated data stores and region moves.
8. AWS: Reducing the scope of impact with cell-based architecturedocs.aws.amazon.comCells, partition keys, the thin cell router and a control plane that migrates customers; with 10 cells a failure in one leaves 90% of requests unaffected.
9. Shopify Engineering: A pods architecture to allow Shopify to scaleshopify.engineeringPods: groups of shops on fully isolated datastores behind shared app servers and workers, with a load-balancer router and per-pod failover.
10. Shopify Engineering: Shard balancing, moving shops with zero downtimeshopify.engineeringUneven shard load (almost 4× between least and most used) and the online move: batch copy, binlog tailing, a short write lock, a routing update, then cleanup.