Glossary · 4 · Platform SDKs and extensions
Multi-tenancy
Also known as: Multitenancy, Multi-tenant architecture
German: Mandantenfähigkeit
In software architecture, multi-tenancy is an arrangement in which one instance of an application or service serves several customers (tenants), each with its own data, configuration and users, kept logically isolated from the other tenants while the underlying resources are shared.
- Platform SDKs
- Security
In one sentence
Multi-tenancy lets one software instance serve several customers (tenants) with isolated data and configuration on shared resources.
Example
A cloud ticketing platform runs one application for hundreds of companies; an extension installed by one company sees only that company's tickets, users and settings.
How it applies
- Platform SDKs: An extension built with the SDK of a multi-tenant platform runs inside a shared service. The SDK and the platform decide which tenant's data an extension may read, usually through tenant-scoped authorization and installation per tenant. Extension code must never assume that it is the only customer of the service.
- Developer SDKs: Client libraries of multi-tenant APIs pass a tenant or organization identifier with every call, often derived from the credential. Quotas and rate limits are usually counted per tenant.
- Hardware SDKs: Device fleets connected to a shared cloud service are assigned to tenants; device identities and telemetry streams are separated per tenant.
- Publishing SDKs: Hosted documentation and content delivery services keep the content, branding and access rules of each customer apart while sharing one publishing engine.
- Documentation: Extension and API documentation should state what is isolated per tenant (data, configuration, users, limits), what is shared (code version, release schedule, maintenance windows) and which settings an extension may change for its tenant only.
Multi-tenancy vs. single-tenancy
In a single-tenant deployment each customer gets its own instance of the application, sometimes on dedicated infrastructure. Multi-tenancy shares the instance and isolates tenants logically; single-tenancy isolates them by deployment. The choice affects upgrades (one version for all tenants vs. per-customer versions), customization (configuration and extensions vs. code changes) and the evidence a provider can give about separation. Neither model makes a service secure by itself; isolation has to be designed, implemented and tested.