IssueRaiser

[NEW] Support for Active/Active replication

**Active Issues**: https://github.com/pes-innovation-lab/valkey/issues ## Overview **What problem are we solving?** Valkey today has a single writable primary per shard. Serving a globally distributed application therefore forces one of two painful choices: route every write across to one primary region while paying tens to hundreds of milliseconds of cross-region latency on the write path and losing all write availability when that region is unreachable or stand up an external replication pipeline (a message broker plus a custom sync service) that mirrors data between regions. The external pipeline adds operational surface, extra network hops, its own failure modes, and a lag/consistency model that lives outside Valkey and outside the commands users already know. Neither option lets an application in any region read and write its local Valkey at low latency while staying converged with its peers. **Who is the user?** Operators running Valkey behind globally distributed applications for use cases like multi-region session stores, user profiles, shopping carts, feature flags, counters, rate limiters, and edge caches. The users who need local read/write latency in every region and continued availability during a regional outage or cross-region partition. These customers are willing to accept eventual (rather than strong) consistency in exchange for local latency and always-writable regions, and they do not want to build or operate a separate cross-region sync tier to get it

Posted by btzq on May 17, 2024, 2:44 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments

reliability (Network)

[NEW] Support for Active/Active replication

btzqMay 17, 2024, 2:44 PM

**Active Issues**: https://github.com/pes-innovation-lab/valkey/issues ## Overview **What problem are we solving?** Valkey today has a single writable primary per shard. Serving a globally distributed application therefore forces one of two painful choices: route every write across to one primary region while paying tens to hundreds of milliseconds of cross-region latency on the write path and losing all write availability when that region is unreachable or stand up an external replication pipeline (a message broker plus a custom sync service) that mirrors data between regions. The external pipeline adds operational surface, extra network hops, its own failure modes, and a lag/consistency model that lives outside Valkey and outside the commands users already know. Neither option lets an application in any region read and write its local Valkey at low latency while staying converged with its peers. **Who is the user?** Operators running Valkey behind globally distributed applications for use cases like multi-region session stores, user profiles, shopping carts, feature flags, counters, rate limiters, and edge caches. The users who need local read/write latency in every region and continued availability during a regional outage or cross-region partition. These customers are willing to accept eventual (rather than strong) consistency in exchange for local latency and always-writable regions, and they do not want to build or operate a separate cross-region sync tier to get it

Comments (0)

No comments yet. Start the discussion.

Comment on this issue