A safe Spring Boot multi-tenant design starts by resolving the tenant from a trusted, authenticated identity—not from an unchecked request parameter—and carrying that tenant through every database and cache operation. For MongoDB, choose either a database per tenant or shared collections with a mandatory tenantId field. For Redis, make every key tenant-aware and enforce ownership checks as well as key naming. The strongest safeguards are centralized tenant-scoped access paths and negative tests that try to cross tenant boundaries.
Choose how MongoDB will separate tenant data
The main decision is whether each tenant gets a separate database or tenants share collections distinguished by a tenant field. MongoDB’s Atlas multi-tenant guidance describes both approaches and their trade-offs.
| Consideration | Database per tenant | Shared collections with tenantId |
|---|---|---|
| Best fit | A small, stable tenant population, varying tenant requirements, or a need for database-level access controls. | A tenant population that may grow indefinitely, with largely uniform schemas and query patterns. |
| Isolation | Provides a database boundary and can support tenant-specific database-user restrictions. | Logical separation depends on the application including and enforcing the tenant predicate for every operation. |
| Indexes and uniqueness | Indexes can be tailored to each tenant, at the cost of duplicated collections and indexes. | Include tenantId in compound indexes and in uniqueness constraints wherever uniqueness must be tenant-specific. |
| Operations | Tenant-specific migration, scaling, and access policies can be applied at database scope. Many databases can add redundant collections and indexes, open-file and memory pressure, and cluster scale limits. | Fewer duplicated structures and simpler maintenance, but tenant isolation must be consistently enforced in application code. |
| Sharding and movement | Evaluate shard placement against workload and locality needs; moving collections has operational overhead. | MongoDB’s movable-collections guidance says tenant data is generally kept on a single shard. Keep a tenant’s collections together when cross-collection operations or transactions need locality. |
MongoDB advises against creating a separate collection for every tenant inside one shared database: that design increases application complexity and creates long-term scaling problems. The comparison is architectural, not a performance ranking; benchmark with tenant-shaped workloads rather than assuming one layout will be faster.
Resolve and carry tenant identity safely
Derive the tenant from an authenticated claim, a trusted host-to-tenant mapping, or another request-bound identity source. Do not let an arbitrary client-supplied tenant identifier choose the database or scope a query without authorization. Authentication identifies the caller; authorization must also establish that caller may act for the selected tenant.
#1 Best Overall
- Authenticate and resolve: At the application edge, map the trusted identity to a tenant ID.
- Authorize: Verify that the caller may operate for that tenant before running tenant data operations.
- Set context: Store the resolved ID in an immutable request-scoped tenant context and make it available to the service layer.
- Use scoped access: Require tenant-scoped repository methods or a service layer that injects the tenant condition into database access.
- Clean up: Clear request context in completion or
finallylogic, including failure paths, so one request cannot leave identity behind for another.
The request-context lifecycle shown in Redis OM Spring documentation illustrates interceptor setup and cleanup; apply the same lifecycle discipline to MongoDB access. If work leaves the request path, ensure the tenant identity is explicitly carried into that work rather than assuming request context will follow it.
Implement the MongoDB access pattern
For database-per-tenant
Spring Data MongoDB’s MongoTemplate can be created with a MongoClient and database name, or with a MongoDatabaseFactory. The factory-based construction supports a database-selection strategy, making it suitable for selecting a tenant database after the tenant has been resolved and authorized.
Keep tenant-to-database selection in one controlled component. Services should not accept a database name from request data or assemble database access ad hoc. Configure the template and selection mechanism centrally; Spring Data documents MongoTemplate as thread-safe after configuration, so tenant selection belongs in the configured factory strategy or operation-scoped routing logic, not mutable per-request template reconfiguration.
For shared collections
Store a tenant identifier on every tenant-owned document. Apply that predicate to every read, update, and delete—not only list endpoints—and include it in uniqueness rules so the same business key can exist independently for different tenants when required.
Recommended Free Tools
// Illustrative access rule, not a complete repository implementation:
query = { tenantId: authenticatedTenantId, resourceId: requestedResourceId }
update = { tenantId: authenticatedTenantId, resourceId: requestedResourceId }Centralize predicate injection in tenant-scoped repositories or service methods. A query that filters only by a resource ID can return or modify another tenant’s record if identifiers overlap or are guessed. Compound indexes should begin with tenantId for shared-collection access patterns, and unique indexes should incorporate tenantId where uniqueness is tenant-local.
Prevent Redis cache and keyspace leakage
Use a canonical tenant-aware key format such as tenant:{tenantId}:{resourceType}:{resourceId} for cache entries, sessions, locks, rate limits, and pub/sub-related keys. Centralize key construction in a helper or service that requires a tenant ID; do not allow callers to create tenant-owned keys by passing only a resource identifier.
Rank #4
Redis recommends tenant-aware naming alongside ACL key-pattern restrictions and application checks as defense in depth. Key prefixes are not a substitute for authorization: validate ownership before returning cached data, and make the tenant context part of both the read and write paths. Redis has noted that cache leaks often result from missing tenant context on a read or write path, including use of the wrong prefix.
If using Redis OM Spring
Redis OM Spring supports tenant-specific index names, key prefixes, and a thread-local RedisIndexContext, as well as static and runtime tenant keyspace resolution through custom keyspace resolvers. However, its documentation warns that context-based routing is not consistently applied automatically across all repository and EntityStream query paths. For strict isolation, include an indexed tenant field, scope repository and query facades explicitly, and check ownership before returning a result.
Build the controls into the request path
Spring Boot provides MongoDB and Redis starters and auto-configuration for their integrations. Its MongoDB connection properties and factories, along with Redis abstractions such as RedisConnectionFactory, StringRedisTemplate, and RedisTemplate, provide the infrastructure; tenant isolation still has to be designed into your own access paths.
- Resolve a tenant only from a trusted identity source and confirm the caller is permitted to act for it.
- Set immutable request-scoped context and guarantee cleanup after completion.
- Expose MongoDB operations through tenant-scoped methods; for shared collections, ensure each query and mutation includes the tenant condition.
- Centralize Redis key construction so tenant IDs cannot be omitted from tenant-owned keys.
- Review indexes and unique constraints against actual tenant-scoped query patterns.
- Log tenant ID, request ID, operation, and outcome for diagnosis, without logging secrets or cross-tenant payloads.
Test isolation by trying to break it
Happy-path tests show that a tenant can access its own records. Isolation tests must also attempt to access another tenant’s data. Use at least two tenants with overlapping or deliberately reused resource identifiers so missing scope is observable.
- Try cross-tenant reads, including direct lookup by resource ID.
- Try cross-tenant updates and deletes and verify the other tenant’s document remains unchanged.
- Try cache hits with the wrong tenant context, including reads after a different tenant has populated a similar resource key.
- Try to access another tenant’s locks and sessions.
- Test exception and request-completion paths to verify tenant context is cleared.
- For Redis OM Spring, exercise each repository and
EntityStreamquery path your application uses rather than assuming context-based routing covers them all.
No general benchmark establishes which MongoDB tenancy layout performs best. Measure with realistic tenant counts, data sizes, index shapes, and request mixes before choosing or changing the architecture.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
