Custom Object Microservices for Tenant-Specific Data Models
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
SaaS companies face challenges in customizing a fixed data model on a per-tenant basis, leading to significant re-implementation costs and data migration requirements due to the need for tenant-specific objects in a multi-tenant system.
Innovation Solution
Implementing a standalone custom object microservice and query microservice to enable real-time joins across custom and global objects, allowing tenant-specific customization without database joins, using a monolithic application extended with custom field services.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a fixed data model is used common across all tenants, then system simplicity and ease of operation are improved, but adaptability for tenant-specific customization deteriorates
Solution Approach 1:
The patent segments the data model into a fixed common data model shared by all tenants and tenant-specific custom objects. The custom object microservice allows each tenant to define and manage their own custom objects separately from the core system, enabling customization without affecting the base system operation.
Solution Approach 2:
The patent extracts the customization functionality from the monolithic application into a separate custom object microservice. This allows tenant-specific custom objects to be defined and managed independently through APIs, while the main application continues to operate with the fixed data model unchanged.
2Adaptability or versatility
If custom fields are implemented using a new database table with database joins, then adaptability for tenant-specific customization is improved, but device complexity and re-implementation costs worsen
Solution Approach 1:
The patent segments custom field storage into a separate custom objects table distinct from the main data model tables. Each tenant's custom objects are stored independently with their own schema, eliminating the need for complex database joins between custom and core data.
Solution Approach 2:
The patent introduces a custom object microservice as an intermediary layer between the application and the data model. This microservice handles all custom object operations through APIs, abstracting away the underlying data storage complexity from the main application logic.
3Loss of information
If database joins are performed to combine data from main table and custom fields, then data completeness is improved, but productivity and performance deteriorate
Solution Approach 1:
The custom object microservice acts as an intermediary that retrieves and combines custom object data with main data model results at the application layer rather than through database joins. This maintains data completeness while improving query performance by avoiding complex join operations.
Solution Approach 2:
The patent extracts the data combination logic from the database layer to the application layer. The microservice fetches custom objects separately and merges them with main data model results in memory, eliminating the performance overhead of database joins while preserving complete data.
4Ease of operation
If a monolithic application structure is used, then ease of operation is improved, but adaptability for tenant-specific customization deteriorates
Solution Approach 1:
The patent segments the monolithic application into a core application handling the fixed data model and a separate custom object microservice handling tenant-specific customizations. This microservice architecture allows independent development, deployment, and scaling of customization functionality.
Solution Approach 2:
The custom object microservice provides universal customization capabilities that can serve multiple tenants with different requirements. The same microservice infrastructure supports various tenant-specific custom objects through a standardized API interface.
Data Source
AI summary
A multi-tenant system, comprises a main storage system including: a monolithic database storing global records associated with global objects, each global object including global fields common for all tenants; a monolithic application configured to process a particular global record storage request by instructing the monolithic database to store particular global field values of the particular global record for a particular tenant, and to process a particular global record fetch request by instructing the monolithic database to retrieve the one or more particular global field values; a custom object storage system including: a custom object database configured to store custom records associated with one or more custom objects, each custom object including one or more custom fields for a tenant; a custom object record service configured to process a particular custom record storage request by instructing the custom object database to store one or more particular custom field values for the tenant, and to process a particular custom record fetch request by instructing the custom object database to retrieve the one or more particular custom field values; and a query engine configured to receive a query, fetch relevant global records from the monolithic database, fetch relevant custom records from the custom object database, and generate a query response.