SPOC Server Transaction Synchronization Across Distributed Cloud Services

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In distributed cloud-based systems, synchronizing transactions across multiple separate datacenters can lead to timing issues due to notifications being sent before all services have completed their operations, causing inconsistencies and errors.

Innovation Solution

A Single Point of Contact (SPOC) server is introduced to manage transactions across multiple distributed cloud-based services, generating a transaction identifier that directs endpoints to call separate services, and only sends a transaction completion notification once all services have finished, ensuring synchronization and consistency.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Speed

If notifications are sent immediately when individual services complete their operations, then the endpoint receives real-time updates, but timing issues occur and the endpoint may receive notifications before all backend systems have completed their operations and reached internal consistency

Engineering Contradiction:
Improvenotification speedVSAvoidtransaction consistency
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The SPOC server performs preliminary actions by generating a transaction identifier and establishing a completion threshold before individual services execute. It pre-configures the synchronization mechanism by determining how many services must complete before triggering the final notification, thus preventing timing issues while maintaining real-time updates.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The SPOC server acts as an intermediary between individual services and the endpoint. It receives completion notifications from services, tracks their status using the transaction identifier, and only forwards a final notification to the endpoint when the predetermined number of services have completed, ensuring consistency without sacrificing notification speed.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If the system waits for all services to complete before sending any notification, then transaction consistency is maintained, but the endpoint experiences delays in receiving completion updates

Engineering Contradiction:
Improvetransaction consistencyVSAvoidnotification delay
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary configuration by establishing a completion threshold (number of services that must complete) before execution. This allows the system to balance consistency and timing by notifying the endpoint when the threshold is met, rather than waiting for all services, thus reducing notification delay while maintaining reliability.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system changes the parameter of notification triggering from 'all services completed' to 'predetermined number of services completed'. This parameter adjustment optimizes the balance between transaction consistency and notification speed, reducing unnecessary delays while ensuring adequate synchronization.

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If the endpoint calls multiple separate distributed cloud based services independently, then service autonomy is maintained, but synchronization errors occur and the endpoint cannot determine when all services have completed

Engineering Contradiction:
Improveservice independenceVSAvoidtransaction synchronization
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The SPOC server provides universal coordination functionality that works across multiple independent services. It uses a single transaction identifier to track and synchronize completions from different autonomous services, maintaining their independence while ensuring reliable synchronization through a unified coordination mechanism.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system implements feedback by having services report their completion status to the SPOC server, which then monitors the count of completed services against the predetermined threshold. This feedback loop enables the endpoint to reliably determine when sufficient services have completed without compromising service autonomy.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS10009425B1Synchronization of transactions utilizing multiple distributed cloud-based services
Publication Date: 2018.06.26 GEN DIGITAL INC
  • US10009425B1 patent drawing
  • US10009425B1 patent drawing
  • US10009425B1 patent drawing

AI summary

A SPOC server receives a request to initiate a transaction utilizing multiple separate distributed cloud based services located on separate datacenters, from an endpoint. The SPOC server generates a transaction identifier for the transaction. The SPOC server transmits the generated transaction identifier to the endpoint. Receipt of the generated transaction identifier directs the endpoint to call each one of the separate services, with the transaction identifier. Over time, the SPOC server receives a separate service completion notification with the generated transaction identifier from each one of the separate services. Each separate service completion notification indicates that the corresponding service has completed. Only in response to receiving a separate service completion notification from each one of the separate distributed cloud based services, the SPOC server transmits a transaction completion notification with the generated transaction identifier to the endpoint. The transaction completion notification indicates that the transaction is complete.