- 30 Jul 2024
- 2 Minutes to read
- Print
- DarkLight
Multi-Tenant Architecture
- Updated on 30 Jul 2024
- 2 Minutes to read
- Print
- DarkLight
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.
Standard Server vs Multi-Tenant Server
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. |
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.
Physical MT vs Logical Tenancies
Physical MT segregates data into separate databases by default.
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 save 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.
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 the transactional data gets saved into customer-specific data stores.