Sharded Key Registry for Distributed Consensus Latency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Geographically distributed systems face high latency and reduced throughput due to the need for consensus across multiple geographical regions, particularly when using the Paxos algorithm, which increases network costs and limits transaction processing capacity.
Innovation Solution
Implementing a sharded key registry system that allows for parallel consensus transactions and server-side batching of requests, where keys are partitioned into independent shards and processed in batches, reducing the need for frequent communication across geographical regions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If consensus is obtained from multiple geographical regions using the Paxos algorithm, then data consistency and fault tolerance are improved, but network latency and communication costs increase significantly
Solution Approach 1:
The system segments the key registry into multiple independent shards distributed across different geographical regions. Each shard can be accessed independently, allowing the system to obtain consensus from a subset of shards rather than requiring all shards to participate in every consensus operation. This segmentation reduces the communication overhead and latency while maintaining overall system consistency.
Solution Approach 2:
The patent implements local caching mechanisms at each shard that store recently accessed keys and their values. When a read operation is performed, the system first checks the local cache before contacting remote shards. This local quality approach reduces the frequency of remote communications and significantly decreases read latency while maintaining data consistency through periodic cache synchronization.
2Measurement precision
If the master server communicates with all peer servers at every operation, then consensus accuracy is improved, but system throughput decreases to approximately 10 transactions per second
Solution Approach 1:
The system performs preliminary actions by pre-computing and caching consensus results for frequently accessed keys. Before executing a consensus operation, the system checks whether the result is already available in the cache or can be derived from previous operations. This preliminary action approach allows the system to maintain high consensus accuracy while avoiding redundant communication rounds, thereby increasing throughput to tens of thousands of transactions per second.
Solution Approach 2:
The patent creates and maintains copies of the key registry across multiple shards and geographical locations. Each shard holds a copy of the relevant portion of the registry, eliminating the need for the master server to communicate with all peer servers for every operation. The copying mechanism ensures that consensus can be reached with a subset of shards while maintaining the accuracy and consistency of the overall system state.
3Loss of energy
If batched transactions are implemented, then network communication costs are reduced, but client-side batching complexity and consistency maintenance burden increase
Solution Approach 1:
Instead of requiring the client to perform batching and maintain consistency within batches, the patent inverts the approach by implementing batching and consistency management on the server side. The server receives individual transaction requests from clients, automatically batches them, manages the consensus process, and returns results to clients. This inversion significantly reduces client-side complexity while maintaining the network communication benefits of batching.
Data Source
AI summary
Aspects of the disclosure relate generally to reducing latency for consensus in geographically distributed disaster-safe persistent data-store systems. These distributed systems may include registry system having redundant storage for maintaining the system status. Each registry system may include a server and a storage component. Consensus may be achieved by querying all of other servers of the registry system. In one example, the consensus data may be sharded into independent small groups. This may allow for multiple consensus transactions to be generated and run in parallel, which, in turn may reduce the latency. In addition, or alternatively, requests to a server to write or otherwise change the data-store may be batched at the server side. Thus, for the consensus, the server need only communicate with the other servers only once per batch. This may also reduce the latency of the distributed system.