Skip to content

High-Availability

Valkey GLIDE supports high-availability features out of the box. Only minimal configurations are needed.

  • Automatic topology updates.
  • Configurable timeout and reconnect strategies.
  • Automatic command re-routing during failover.
  • Specifying a read strategy controlling how reads are distributed across the cluster.
  • Available lazy connection to nodes.

GLIDE maintains a map of the cluster and automatically updates it when changes occur. For example, if a primary node fails and a replica is promoted, GLIDE detects this change and updates its topology mapping. No additional configuration is required.

GLIDE provides three configurable settings for resilience during failures:

  • Request timeout (default 250ms) — how long a command can take to complete, including retries. Consider increasing this to 1000ms to give commands time to succeed while nodes recover.
  • Connection timeout (default 2000ms) — how long to wait for a TCP/TLS connection to establish. Applies during initial connection and re-connections.
  • Reconnect strategy (exponential backoff) — To avoid retry storms, GLIDE uses an exponential backoff strategy for reconnection attempts.

For more on configuring these, see our timeouts and reconnect strategy guide.

When a cluster node goes down or slots are migrated, GLIDE automatically handles MOVED and ASK redirects from the server. Commands sent to the wrong node are transparently re-routed to the correct one without application intervention. This includes updating the internal topology map so subsequent commands go directly to the right node.

For more on how GLIDE routes commands, see our command routing page.

Configuring read strategies is important for high availability and latency optimization.

By default, GLIDE clients read and write from the primary node. Reading from replicas provides two benefits: reads can continue while a primary is down and it distributes load away from primaries.

GLIDE also supports AZ-affinity routing, which directs reads to replicas in the same availability zone as the client, reducing cross-AZ latency.

For more on configuring read strategies, see our guide.

Lazy connection mode defers physical connections to Valkey until the first command is executed. This allows applications to start up even when nodes are temporarily unreachable — useful during rolling deployments or when startup ordering isn’t guaranteed.

Once the first command is issued, GLIDE establishes connections and proceeds normally. If the server is unavailable at that point, errors surface at command time rather than during client creation.

For more on configuring lazy connections, see our guide.