5 exercises — master the vocabulary of multi-tenant data isolation: pool, silo, and bridge models; row-level security; hybrid isolation; and data residency design.
0 / 12 completed
1 / 12
A SaaS startup is building their first multi-tenant platform. The architect presents three options for tenant data isolation. She calls them pool model, silo model, and bridge model. Which description correctly defines each?
The pool, silo, and bridge models are the three foundational tenant isolation architectures.
Model
Database
Schema
Rows
Pool
Shared
Shared
Mixed — tenant_id column separates tenants
Bridge
Shared
Per-tenant schema
Isolated at schema level
Silo
Per-tenant DB
Per-tenant
Fully isolated
Trade-offs:
Pool model pros/cons:
✓ Lowest operational overhead — one database to manage
✓ Best resource utilisation — tenants share idle capacity
✗ Highest cross-tenant leak risk — one query bug can expose all tenant data
✗ Noisy neighbour risk — one large tenant can degrade all others
Silo model pros/cons:
✓ Strongest isolation guarantee — complete data separation
✓ Ideal for enterprise/regulated customers who require isolation
✗ Operational complexity scales linearly with tenant count (1,000 tenants = 1,000 databases)
✗ Provisioning is slow and expensive
Bridge model pros/cons:
✓ Reasonable isolation (no cross-schema queries by accident)
✓ Easier to implement per-tenant features (e.g. per-tenant indexes)
✗ Still one database — resource contention possible
✗ Schema proliferation (10k tenants = 10k schemas) strains some DBs
Key vocabulary:
• Tenant context — the mechanism that ensures every query is scoped to the correct tenant
• Row-level security (RLS) — a database feature (e.g. PostgreSQL RLS) that enforces pool model isolation at the DB level
2 / 12
During a security review, the reviewer says: "Your pool model implementation relies entirely on application-level tenant filtering. What happens if a developer forgets to add WHERE tenant_id = ? to a query?" What is this failure mode called, and what is the recommended mitigation?
Tenant data leak is the most critical security risk in pool model multi-tenancy — and database-layer RLS is the defense in depth solution.
Why application-layer filtering alone is insufficient:
• A new developer writes a query without the tenant filter
• A code review misses the issue
• An ORM bug silently drops the WHERE clause in edge cases
• A "debug mode" change committed accidentally removes the filter
Row-Level Security (RLS) as defense in depth:
PostgreSQL RLS example: CREATE POLICY tenant_isolation ON orders
USING (tenant_id = current_setting('app.tenant_id')::uuid);
With RLS enabled, even if application code omits WHERE tenant_id = ?, the database automatically applies the policy. A query that would return all tenants' orders instead returns only the current tenant's orders — or 0 rows if the tenant context is not set.
Additional pool model isolation controls:
• Tenant context middleware — sets the database session variable for every request before any query runs
• Integration tests for cross-tenant isolation — automated tests that verify Tenant A cannot access Tenant B's data
• Query audit logging — log and alert on queries that touch more than one tenant's data volume
Key vocabulary:
• Cross-tenant data leak — a security incident where one tenant can read another tenant's data
• Defense in depth — layered security controls: application layer + database layer + audit layer
• Tenant context propagation — the mechanism that carries the tenant identifier through the request lifecycle
3 / 12
A SaaS company starts with a pool model. As they grow, enterprise customers start asking: "Can you guarantee that our data is in a database that no other tenant can access?" The architect proposes a hybrid isolation model. What does this mean?
The hybrid isolation model is the standard mature architecture for SaaS platforms serving both SMB and enterprise customers.
Architecture overview:
• Pool tier: SMB and startup tenants → shared database cluster, shared schema, tenant_id columns
• Silo tier: Enterprise tenants → dedicated database instance (or dedicated cluster), private schema
• Shared application layer: The same application code handles both tiers; the tenant provisioning system records which database connection each tenant uses
Tenant routing mechanism:
① Incoming request arrives with tenant ID (from JWT, subdomain, or header)
② Tenant context service looks up the tenant's database configuration: "Tenant ABC → Database Pool #3" or "Enterprise Corp → dedicated-db.enterprise-corp.internal"
③ Application uses the correct connection for all queries
Commercial rationale:
• Enterprise customers pay a premium for silo isolation — it is a billable differentiator
• SMB customers benefit from pool model economics (shared infrastructure cost)
Key vocabulary:
• Tenant routing table — the data store that maps each tenant ID to its database connection configuration
• Isolation tier — the isolation model assigned to a tenant (pool, bridge, or silo)
• Tenant onboarding pipeline — the automated workflow that provisions the correct isolation tier for a new tenant at signup
4 / 12
An engineering lead uses the phrase "blast radius" during a multi-tenancy architecture discussion: "With the silo model, we reduce the blast radius of any single component failure." What does "blast radius" mean in this context, and how does it apply to tenant isolation choices?
"Blast radius" is one of the most important vocabulary terms in reliability and security engineering — and it directly shapes multi-tenancy architecture decisions.
Blast radius across isolation models:
Pool model blast radius:
• Database outage → ALL tenants impacted simultaneously
• Security incident (data breach) → potentially all tenant data exposed
• Schema migration failure → all tenants experience the same bug
• Blast radius: MAXIMUM (the entire tenant population)
Bridge model blast radius:
• Database outage → all tenants on that DB impacted
• Schema migration failure → all tenants on that schema version impacted
• Blast radius: MEDIUM (all tenants on the shared DB)
Silo model blast radius:
• Database outage → only that tenant impacted
• Security incident → only that tenant's data at risk
• Schema migration failure → only that tenant impacted
• Blast radius: MINIMUM (one tenant)
Design principle: The silo model is not always worth the cost, but for enterprise customers where a security incident would constitute a contractual breach — minimising blast radius is worth the operational overhead.
Key vocabulary:
• Blast radius — the scope of impact when a failure or security incident occurs
• Fault isolation — the architectural property of limiting how far failures can propagate
• Noisy neighbour blast radius — how many tenants are affected when one tenant abuses shared resources
5 / 12
A multi-tenant SaaS platform is planning to extend internationally. New European customers require data residency — all their data must stay within the EU. Existing North American customers have no such requirement. How should the tenant isolation architecture handle this, and what vocabulary describes this design?
Geo-isolated silos are the standard pattern for multi-tenant SaaS platforms serving customers with data residency requirements.
Architecture design:
① Tenant configuration store records each tenant's residency region: { tenantId: "eu-corp-1", residencyRegion: "eu-west-1", dbEndpoint: "db.eu-west-1.internal" }
② Application layer is deployed multi-region (e.g. us-east-1 + eu-west-1 + ap-southeast-1)
③ Global tenant router (e.g. CloudFront + Route 53 latency routing OR an API gateway with geo-routing) directs EU tenant requests to the EU application tier
④ The EU application tier only connects to EU-region databases — EU tenant data never touches US infrastructure
Key GDPR/data residency vocabulary:
• Data residency — the legal requirement that data must be stored within a specific geographic region
• Data sovereignty — the principle that data is subject to the laws of the country where it is stored
• Data localisation — stricter than residency; requires data to be processed (not just stored) within a jurisdiction
• Cross-border data transfer — moving data between jurisdictions; regulated under GDPR Chapter V
• Sub-processor addendum — contractual requirement for cloud services used to process EU personal data
6 / 12
Reviewer: 'I'm seeing a potential issue with the `CustomerOrders` table. The query doesn't include a tenant ID filter, and we're storing all customer order data in a single pool. This could lead to unauthorized access if a malicious actor gains control of an account.' What is the reviewer primarily concerned about regarding this scenario?
The reviewer is highlighting a critical security risk: the lack of tenant isolation. Without filtering by `tenant_id`, one tenant's data could be inadvertently accessed or modified by another. This is a classic example of a 'blast radius' scenario – the potential damage from a compromised account expands significantly due to the shared resource.
7 / 12
Dev1 (in a Slack channel): 'Just finished implementing the bridge model. Seems like we're using a common database for core services but routing tenant-specific data through separate schemas. Should be fairly robust!' What is Dev1 primarily describing?
Dev1 is describing the bridge model, a common multi-tenant approach. This architecture leverages a shared foundation (core services) while maintaining data isolation through separate schemas and potentially schema mappings – this is key to its flexibility and scalability compared to purely siloed or pooled approaches.
8 / 12
Code Review Comment: 'I'm noticing a potential performance bottleneck here. The query against the `users` table is running without a tenant ID filter. While this might be acceptable for our free tier users, it introduces significant risk of data leakage if we ever expand to enterprise clients requiring stricter isolation. Should we add a WHERE tenant_id = ? clause?' What does this comment primarily highlight regarding multi-tenancy concerns?
This comment focuses on the critical issue of missing tenant isolation. The core concern isn't about indexing or database servers, but rather that the query *lacks* the fundamental filter needed to prevent one tenant's data from being accessed by another. Adding the WHERE clause is essential for mitigating this risk.
9 / 12
Slack Message: '@john.doe Just ran some tests on the new multi-tenant setup. It's great to see the automated tenant routing working smoothly – but I'm worried about a scenario where a developer accidentally modifies the `tenant_metadata` table, potentially affecting other tenants. Is there any built-in protection against this kind of unintended side effect?' What is John Doe most concerned about regarding multi-tenancy?
John's concern centers around unintended consequences – specifically, a developer modifying the `tenant_metadata` table. This represents a significant risk because tenant metadata often contains critical information used for isolating tenants; changes here could have widespread and unpredictable effects on other tenants' data.
10 / 12
PR Description: 'Implemented the bridge model. This architecture utilizes a shared database for common services like authentication and logging, while tenant-specific data resides in separate schemas managed by an identity layer. This design offers flexibility but introduces complexities around schema management and potential cross-tenant dependencies. We've added detailed documentation outlining our approach to ensuring data isolation.' What is the *primary* benefit of using a bridge model as described here?
The PR explicitly states that the bridge model's primary benefit is 'enhanced data isolation.' While flexibility and schema management are considerations, the core goal – preventing tenants from accessing each other's data – is achieved through the separate schemas managed by the identity layer.
11 / 12
Standup Update: 'I've been working on implementing the silo model. The idea is that each tenant gets its own completely separate database instance – no shared resources whatsoever. It's a significant investment in terms of infrastructure, but it provides the strongest possible isolation.' What is the *main* characteristic of the silo model being described here?
The description explicitly states that each tenant gets 'its own completely separate database instance.' This fundamental characteristic defines the silo model: complete isolation – meaning no shared resources or a centralized data repository. It's about maximum separation.
12 / 12
Scenario: 'Our SaaS platform is expanding into the UK and Ireland to comply with GDPR. We need to ensure that customer data for UK-based clients remains within the EU's jurisdiction. Given our current multi-tenant architecture – which currently uses a pool model with a single global database – how should we approach this requirement?'. What architectural change would most directly address this data residency concern?
To satisfy GDPR requirements regarding data residency (keeping UK/Irish client data within the EU), the most direct solution is to move tenant data to separate databases *per region*. This physically separates the data, ensuring compliance with regulations that mandate where data must be stored.
What will I practise in "Tenant Isolation Models Vocabulary"?
This module focuses on Multi-Tenant SaaS Architecture — real workplace phrasing you'll use on the job. It contains 12 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 12 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Multi-Tenant SaaS Architecture exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around multi-tenant saas architecture — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Multi-Tenant SaaS Architecture exercises?
See the Multi-Tenant SaaS Architecture hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.