Multi-Master Data Sync with Automatic Error Replay
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing business application synchronization methods often lead to object inconsistencies and errors due to reliance on a single designated master, especially as the number of applications grows, and do not effectively handle snapshot, delta, and long-running process changes across multiple systems.
Innovation Solution
A multi-master data synchronization architecture that reduces changes into snapshot, delta, and long-running process changes, incorporating automatic error retry logic and backup/restore capabilities to ensure conflict-free and complete synchronization across business applications.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a single designated master is used to impose changes in the business system, then the synchronization process is simple to manage, but object inconsistencies occur when the master does not have the latest information
Solution Approach 1:
The patent divides the single-master synchronization model into multiple independent master applications, where each application can act as a master for specific data entities. This segmentation allows distributed decision-making while maintaining data consistency through event-driven synchronization and change logging mechanisms.
Solution Approach 2:
The patent introduces an intermediary synchronization mechanism that uses change logs and event processing to mediate between multiple master applications. This intermediary layer ensures that changes are properly propagated and conflicts are resolved without requiring a single designated master.
2Adaptability or versatility
If the number of business applications grows to synchronize data between front office and back office applications, then comprehensive data coverage is achieved, but synchronization complexity increases
Solution Approach 1:
The patent creates a universal synchronization framework that can handle multiple types of changes (snapshot, delta, long-running process) across different application domains. This multi-functional approach allows the same synchronization mechanism to serve front office, back office, and intermediate applications without requiring domain-specific implementations.
Solution Approach 2:
The patent implements dynamic synchronization where applications can be added or removed from the synchronization network without restructuring the entire system. The change logging and event processing mechanisms adapt dynamically to accommodate growing numbers of applications while maintaining manageable complexity.
3Quantity of substance
If snapshot changes are synchronized where only after-change results matter, then storage requirements are reduced, but information loss occurs during the change process
Solution Approach 1:
The patent applies different quality levels of change tracking to different data entities based on their specific requirements. Some entities use snapshot changes (storing only after-change results) while others use delta changes (storing before and after states), allowing optimization of storage versus information retention on a per-entity basis.
4Loss of information
If delta changes are tracked where both before and after change information is stored, then complete change information is preserved, but storage requirements increase
Solution Approach 1:
The patent applies different quality levels of change tracking to different data entities based on their specific requirements. Some entities use snapshot changes (storing only after-change results) while others use delta changes (storing before and after states), allowing optimization of storage versus information retention on a per-entity basis.
Data Source
AI summary
Architecture for synchronizing data between business applications according to a multi-master arrangement. Changes to business entities can be snapshot changes, delta changes, and long-running process changes, the latter which can be derived from the first two. The architecture includes automatic error retry logic, such that when synchronization errors occur, the logic can be replayed to resolve the errors, when conditions have changed where the errors can be resolved. This also applies to when one error causes a cascading set of errors. By replaying one error, the other errors will be resolved. Backup and restore of a participating application is also provided such that a new data change in a non-backup-restored application will automatically be synchronized to the recently-restored system.