Multi-tenancy Metadata Layer for Single Codebase Applications
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current electronic contract management applications require separate instances of code to be developed, deployed, and operated for each tenant, leading to high development and maintenance costs, making them unaffordable for some businesses, especially when they need to support multiple tenants with different requirements for presentation, business rules, workflows, and security.
Innovation Solution
A system and method that enables multi-tenancy by establishing tenancy information for users, customizing requests and results using a multi-tenancy metadata database, allowing a non-tenant aware application to support multiple tenants with a single code base, thereby reducing hosting costs and increasing scalability.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If separate instances of code are developed and deployed for each tenant, then customization requirements for different tenants are met, but development and maintenance costs increase significantly
Solution Approach 1:
The system segments tenancy configuration into separate metadata files for each tenant, allowing independent customization without modifying the core application code. Each tenant's requirements (presentations, business rules, workflows, security) are stored in separate metadata files that can be loaded and applied at runtime, enabling customization while maintaining a single shared codebase.
Solution Approach 2:
The system performs preliminary configuration by pre-defining tenant metadata including presentations, business rules, workflows, and security settings in metadata files before the application runs. This preliminary action allows the application to load and apply tenant-specific configurations without requiring separate code instances or runtime modifications.
2Adaptability or versatility
If separate instances of code are deployed for each tenant, then tenant-specific requirements are supported, but the system becomes less affordable for some businesses
Solution Approach 1:
The system implements a universal application instance that can serve multiple tenants simultaneously by loading different tenant metadata configurations. The single application instance is designed to be multi-functional, adapting its behavior based on the loaded tenant metadata, thereby eliminating the need for separate code instances while maintaining full tenant-specific functionality.
Solution Approach 2:
The system changes operational parameters by loading different tenant metadata configurations that define presentations, business rules, workflows, and security settings. Instead of changing the codebase for each tenant, the system modifies runtime parameters through metadata files, allowing the same application instance to adapt to different tenant requirements at no additional development cost.
3Device complexity
If a single code base with configuration options is used, then development costs are reduced, but scalability and performance may be compromised
Solution Approach 1:
The system adds a metadata configuration dimension to the single codebase architecture. Instead of scaling horizontally with separate code instances, the system scales by loading different tenant metadata configurations into the single instance. This dimensional change allows the system to maintain a single codebase while achieving multi-tenant scalability through configuration space rather than instance multiplication.
Solution Approach 2:
The system introduces tenant metadata files as an intermediary layer between the single application instance and tenant-specific requirements. These metadata files act as mediators that translate tenant customization needs into configuration parameters that the application can apply without modifying its core logic, thereby maintaining both low development cost and high scalability.
Data Source
AI summary
A method for providing multi-tenant services includes receiving a request from a user, establishing tenancy information for the user, wherein the tenancy information is selected which corresponds to a tenant of the user from among multiple tenants, customizing the request according to the tenancy information established for the user, forwarding the request to an application that is not multi-tenant aware, receiving results of the request from the application, customizing the results according to the tenancy information established for the user and corresponding to the tenant of the user, and returning customized results to the user.