Multi-tenancy
Multi-tenancy supports separate customer or group scopes in one solution. A tenant is not automatically one person or one database.
Multi-tenancy means that software supports multiple logically separated customers or groups as tenants. A tenant might be a company with several users. How people and data are assigned must be clearly defined.
Example and architectural boundary
In a hypothetical application, different companies use the same product. Their orders remain within the permitted company scope. If someone is to belong to multiple scopes, membership and switching need clear rules.
Implementation can use shared or separate resources; a single database is not a prerequisite. Multi-tenancy alone does not prove secure isolation either. Access through lists, files, interfaces and background processing must actually respect the intended boundaries. Intentionally shared data needs its own explicit rule.
Sources
Related terms
- Role-based access controlRBAC connects permissions to roles and assigns people to those roles. The data scope must be clear alongside the role name.
- Attribute-based access controlABAC evaluates access using defined properties and rules. The origin and freshness of those properties are part of the design.
- Legacy systemAn existing system still in use, with technical and business dependencies accumulated over time.
- Browser cacheThe browser cache stores suitable HTTP responses for later use. Reuse and revalidation follow the applicable rules.
- Cache invalidationCache invalidation ends reuse of a stored copy under defined rules. The source record remains a separate concern.
- CachingCaching reuses stored data or results. Validity and the permitted user scope belong in the design.
Articles on this topic
Software Development with ASES
Custom software, web and mobile apps