Active/Active use cases

[AtharvaGore]

Primary Benefits of Active/Active Replication

1. Active-Active Geo-Distributed Workloads
   Deploying nodes in multiple regions (e.g., US-East, EU-West) where each node serves local clients. Writes in one region replicate to others, reducing latency for globally distributed apps. Ideal for real-time systems like gaming leaderboards, session stores, or collaborative editing tools needing low-latency writes across regions.

2. High Availability and Write Scalability
   Eliminates single-master bottlenecks since all nodes accept writes, improving throughput. Suitable for workloads requiring continuous write availability (e.g., IoT telemetry ingestion, logging).

Potential Use Cases Documented by Valkey Users

• Multi-Region Caching
  With a multi-region DR architecture, if the cache is not multi-region, traffic shifting from one region to another can result in a large number of cache misses. This puts additional load on the backend database as the missing cache entries are replenished, potentially overwhelming it.

  An active-passive cache setup works well for only two regions. Two active-passive clusters are created, with one cluster active in each region and the other passive. When one region is evacuated, its traffic shifts to the other region, and the passive cluster fails over at the same time. The healthy region then has two active cache clusters. This makes it complicated to determine which cluster should handle a given read or write.

  This approach also does not scale well beyond two regions. Traffic from an evacuated region may need to be distributed across multiple other regions, while only one cluster can be active at a time. An active-active setup avoids this issue by allowing any available region to handle both reads and writes.

[Lazerbeak12345]

I don't know if you're looking for feedback, but I can say I'm among the users with the HA usecase.

My Valkey instances will be hosted in a few different places across town, but it's known that some of these regions may go down for days at a time (at worst).

From an implementer's perspective, I don't expect Valkey to keep a journal (or the like) so many days long, so a compromise where either the difference is sent over the wire or where the entire DB is redownloaded may be acceptable, even more so if it can download the bulk of that over S3, which is already replicated (EX: redownloads the most recent S3 backup then downloads the journal).

Falling back to an error state that I can detect with a bash script, in the event that it is too old to get the data from its peers, is also a viable solution. I could implement the example from the previous paragraph myself using said bash script. (I don't know if that'd be a hook or something else, though).