REST Layer Filter for Distributed Server Configuration Replication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing solutions for synchronizing configurations across distributed servers are cumbersome, requiring comprehensive changes to service functionality and are not practical due to network latency, and often result in divergent copies that require manual merging and human intervention.
Innovation Solution
A method and system that intercepts client requests, creates unique identifiers, and uses a distributed synchronization system to ensure all servers process requests in a consistent order, allowing for synchronous replication of configuration changes with minimal changes to existing service code and logic centralized in a single layer.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If configuration changes are replicated at the persistence level using low-level data storage mechanisms, then configuration synchronization is achieved, but comprehensive changes to service functionality are required
Solution Approach 1:
The patent shifts the replication mechanism from the persistence layer (data storage level) to the REST layer (application level). By injecting a filter at the REST layer, configuration changes are intercepted and replicated before reaching the persistence layer, thus achieving synchronization without modifying service functionality or data storage mechanisms.
Solution Approach 2:
The patent introduces a REST layer filter as an intermediary component that sits between the client and the service. This filter captures configuration changes, serializes them, and republishes them to a topic exchange, enabling synchronization without direct modifications to existing service code or persistence mechanisms.
2Reliability
If all users access the service in a single location, then configuration consistency is maintained, but network latency prevents practical implementation across geographic sites
Solution Approach 1:
The patent divides the centralized service into multiple geographically distributed instances, each capable of independently processing requests. The filter at each instance captures local configuration changes and replicates them to other instances via message brokering, enabling distributed operation while maintaining consistency.
Solution Approach 2:
The system implements a feedback mechanism where configuration changes are published to a topic exchange and subscribed to by all service instances. Each instance receives updates from others and applies them locally, creating a continuous feedback loop that maintains synchronization across the distributed system.
3Reliability
If configuration changes are replicated synchronously across all servers, then identical states are maintained, but network delays may cause processing bottlenecks
Solution Approach 1:
The filter serializes configuration changes and publishes them to the topic exchange before the actual service processing completes. This preliminary action allows other instances to receive and queue the changes in advance, reducing the impact of network delays on overall system productivity.
Solution Approach 2:
The system maintains continuous operation by allowing the originating instance to process the request immediately while replication occurs in parallel. Other instances continue processing their own work and apply replicated changes when received, ensuring uninterrupted service delivery despite asynchronous replication delays.
Data Source
AI summary
Replicating configuration among distributed servers. A filter running on a server, the server being one of the distributed servers, intercepts a request from a client device to the server. The filter creates a unique identifier for the request and blocks the request from being processed at the server. A replicator running on the server sends the request with the unique identifier for synchronizing the request with one or more other requests received from one or more of the distributed servers. The replicator also receives an ordered list of one or more synchronized requests each annotated with a respective unique identifier. The server processes the ordered list of one or more synchronized requests having the respective unique identifier. The ordered list may include the request that is being blocked, wherein the blocked request is processed at the server responsive to receiving request as part of the ordered list.