Hub Spoke Data Sync via One-Way Requests

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In cloud computing systems, maintaining synchronization between a hub client instance and spoke client instances, especially in more restrictive environments with higher security requirements, is challenging due to differing regulatory conditions that restrict bidirectional data communication, leading to potential data inconsistencies and errors during synchronization.

Innovation Solution

A cloud computing system architecture that includes a hub client instance and spoke client instances, where spoke client instances are generated by copying the hub client instance, with one-way data synchronization allowing spoke clients to request and receive updates from the hub client instance while blocking incoming requests, ensuring data consistency and compliance with restrictive environment rules.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If bidirectional data communication is implemented between hub and spoke client instances, then data synchronization capability is improved, but compliance with restrictive environment rules deteriorates

Engineering Contradiction:

Improvedata synchronization capabilityVSAvoidcompliance with restrictive environment rules

Core Design Contradiction:

ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The patent segments the bidirectional communication channel into two separate unidirectional channels: one from hub to spoke for data distribution, and another from spoke to hub for change requests. This segmentation allows the system to maintain data synchronization while complying with restrictive environment rules that prevent the spoke from receiving arbitrary incoming requests.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

Instead of the hub initiating data push operations to spoke instances (traditional approach), the invention inverts the control flow by allowing the spoke to initiate change requests to the hub. The hub then responds by pushing only the specific change data requested, rather than pushing all data proactively.

Inventive Principle:

Principle #13The other way round (Inversion)

2Object-affected harmful factors

If one-way data requests are implemented from spoke to hub, then compliance with restrictive environment rules is improved, but data synchronization efficiency deteriorates

Engineering Contradiction:

Improvecompliance with restrictive environment rulesVSAvoiddata synchronization efficiency

Core Design Contradiction:

Object-affected harmful factorsVSProductivity

Solution Approach 1:

The system implements a feedback mechanism where the spoke client monitors its local data tables for changes, and when changes are detected, it sends a targeted request to the hub client. The hub responds with the specific change data, creating an efficient feedback loop that maintains synchronization without requiring continuous polling or broad data pushes.

Inventive Principle:

Principle #23Feedback

Solution Approach 2:

The spoke client instance performs preliminary monitoring of its local data tables to detect changes before requesting updates from the hub. This preliminary detection action allows the system to request only necessary data changes rather than synchronizing all data, improving efficiency while maintaining compliance.

Inventive Principle:

Principle #10Preliminary action

3Speed

If the hub client initiates data pushes to spoke clients, then data distribution speed is improved, but control over restrictive environment compliance deteriorates

Engineering Contradiction:

Improvedata distribution speedVSAvoidcontrol over restrictive environment compliance

Core Design Contradiction:

SpeedVSObject-affected harmful factors

Solution Approach 1:

The patent implements a dynamic communication model where the direction and timing of data flows are determined by actual change events rather than fixed schedules. The hub pushes data to the spoke only when the spoke requests changes, making the data distribution speed responsive to actual synchronization needs while maintaining compliance with restrictive environment rules.

Inventive Principle:

Principle #15Dynamics

Data Source

PatentUS11140223B2Systems and methods for synchronizing data between hub and spoke environments

Publication Date: 2021.10.05 SERVICENOW INC

AI summary

A cloud computing system includes a hub client instance and at least one spoke client instance that is generated based on copying the hub client instance. The hub client instance includes hub objects maintained using hub object tables, and the spoke client instance includes spoke objects that are copied from the hub objects and are maintained using spoke object tables. To synchronize the spoke client instance with the hub client instance, the spoke client instance requests data indicating changes made to the hub object tables. The request may be one-way, such that the spoke client blocks or prevents requests from the hub client instance. In response to receiving the request, the hub client instance sends the data indicating changes made to the hub object tables to the spoke client instance. The spoke client instance updates the spoke object tables based on the data.