Multi-Instance Tenant System Hub Satellite Directory Merge
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current computing systems face difficulties in managing the merger of tenants, as they typically support only a single instance per tenant, making it challenging to merge or grow tenants by adding data containers, which limits user visibility and content sharing across merged entities.
Innovation Solution
A multi-instance tenant computing system is introduced, where a hub tenant and a satellite tenant are identified, with directory and content merger logic re-associating identity account items and content items respectively, using a common tenant identifier, while maintaining unique user identifiers and permissions, allowing seamless integration and sharing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a single instance per tenant is supported, then system simplicity is maintained, but tenant merging and growth capabilities are limited
Solution Approach 1:
The system segments the tenant instance into multiple independent instances (hub instance and satellite instances) that can be independently managed yet collectively serve a single tenant. This allows the tenant to grow by adding satellite instances without fundamentally changing the system architecture, resolving the contradiction between adaptability and complexity.
Solution Approach 2:
The patent implements a nested structure where satellite instances are logically nested within the hub instance framework. The hub instance contains references to satellite instances, and all instances share common tenant identity through nested identity containers. This nesting enables scalable tenant growth while maintaining unified management.
2Ease of operation
If tenant directory systems are merged, then user visibility and content sharing improve, but data management complexity increases
Solution Approach 1:
The hub instance serves multiple functions: it acts as the primary tenant instance, contains identity containers for all satellite instances, and provides unified access points for content sharing. This multi-functionality eliminates the need for complex peer-to-peer merging logic between multiple hub instances.
Solution Approach 2:
The hub instance acts as an intermediary that mediates between satellite instances. Instead of directly merging directories between multiple tenants, the system uses the hub instance as a central coordinator that manages identity containers and content sharing permissions, simplifying the merger process.
3Adaptability or versatility
If multiple instances per tenant are implemented, then tenant growth and merging capabilities are enabled, but system complexity increases
Solution Approach 1:
Each satellite instance has a specific local quality: it maintains its own instance-specific data and configuration while sharing the common tenant identity through the hub instance. This local differentiation allows multiple instances to coexist without requiring complete system-wide changes, managing complexity through localized changes.
Solution Approach 2:
All instances (hub and satellite) share homogeneous characteristics in terms of their identity structure, data models, and interface contracts. They all use the same tenant ID reference mechanism and follow identical operational protocols, which simplifies multi-instance management despite the increased number of instances.
Data Source
AI summary
Directory information and content for two separate tenants are merged by identifying a first of tenants as a hub tenant and a second of the tenants as a satellite tenant. The hub tenant is modified to include two instances, or data containers, one instance for the hub tenant and another instance for the satellite tenant. Directory merger logic re-associates identity account items in the satellite instance, with the hub instance, by replacing a tenant identifier in the identity account items of the satellite instance with a tenant identifier corresponding to the hub instance. Unique identifiers for users of the satellite instance are maintained unchanged. Content merger logic re-associates content items of the satellite instance with the hub instance by setting a tenant identifier for all satellite content items to the tenant identifier corresponding to the hub instance. A tenant identifier corresponding to backend services that support the content items can be updated to the tenant identifier corresponding to the hub instance as well.