Multi-Tenant Architecture
- 22 May 2024
- 3 Minutes to read
- Print
- DarkLight
Multi-Tenant Architecture
- Updated on 22 May 2024
- 3 Minutes to read
- Print
- DarkLight
Article summary
Did you find this summary helpful?
Thank you for your feedback
Multi-tenancy (MT) server architecture allows a single software instance to serve multiple different groups of user accounts that also segregate data at rest.
MT architecture achieves this by separating instances from a designated Control instance into separate Tenant instances running on the same single-host server.
There are three supported deployment methods of MT: physical, standard logical, and segregated logical.
Note:
The tenants must be installed on a database similar to the Control Instance for MT servers. If the Control Instance uses MSSQL, the Tenant Instance should also use MSSQL.
Important!
- If the Tenant and Control Instances are hosted on the same server, it is strictly recommended that both applications be hosted on Information Internet Services (IIS).
- If the Tenant Instances are hosted on separate servers, it is essential to align the hosting configuration of the Tenant Instances with that of the Control Instance. The Tenant Instances should also be self-hosted if the Control Instance is self-hosted, similarly for Internet Information Services (IIS). Ensuring consistency in the hosting environment is essential in such scenarios.
Standard Server vs Multi-Tenant Server
Tenant Instance Limit
MT servers with default resource requirements should not exceed 30 tenants per individual server due to high resource intensity.
| Standard | Multi-Tenant |
|---|---|
Supports only one version of each Flow. | Supports multiple versions of each Flow. |
| Connects to only one database. | Connects to one database per Tenant server and one database for both the Default and Prototype Instances. |
| Initiates via one runtime. | Initiates one runtime per Tenant server. |
| Shares the same Portal/Studio. | Supports individual Portals per Tenant server. |
| It supports one Global Theme with different views, respecting group/account levels. | Supports Tenant servers sharing the same Portal Theme. |
For Standard servers, resource requirements for the host server depend on the usage of the applications running on it.
Furthermore, Administrators control the amount of accessible data and how it is accessed via user context and folder permissions. This allows Administrators to create separate, unique work environments within a single server.
.png)
This diagram depicts a Standard server setup.Physical MT vs Logical Tenancies
Physical MT segregates data into separate databases by default..png)
This diagram depicts a physical MT setup.
Alternatively, Logical Tenancies can be separated into two types: Standard and Data segregated. Consider all process requirements before choosing a method.
Flows do not restrict where data is read or written. Default Data Structures are saved into the server's SQL server database.
Data-segregated logical MT environments instead implement an Integration Layer to access external data sources with the same patterns. In combination with the flexibility of integrating Flow logic, processes may support reading and writing data from both backend-specific and customer-specific databases at runtime.
With other deployment methods, Data Structures cannot be configured to save in different databases. Furthermore, users are not required to save data into the backend database.
This diagram represents a Data Segregated Logical Multi-Tenancy setup.
Use Case Examples
Standard (Physical) Multi-Tenancy
- A customer wants to provide unique work environments to clients while reducing hosting costs.
Physical MT runs multiple instances on one Windows server, which allows each customer to work in their independent environments from one another. Since this is all done with one server, hosting costs are minimal. - A Flow that shares all of its main components amongst all of the customers accessing it. The customer needs to retain the flexibility to handle the biggest customers with custom Workflow versions. Physical MTs allow the ability to run 99% of the customers on the Single-Tenant and break these bespoke customers into their independent Tenants.
Standard Logical Tenancy
- A customer offers an extensive business Rule engine for clients to process transactions. While each client uses the same version of the business Rule engine, each client should have a personalized view of only their transaction data via a customer Portal.
To achieve this, standard logical tenancy allows data separation so customers can only view their data.
Data-Segregated Logical Tenancy
- The example for standard logical tenancy may apply, with the added requirement that transactional data be saved into customer-specific data stores.
Was this article helpful?
