Can Redis Cluster Lose Writes? Why and How to Prevent Them

Introduction

Redis is an open‑source high‑performance key‑value store widely used for caching and messaging. To improve scalability, Redis offers a cluster mode that spreads data across multiple nodes, which raises concerns about possible write loss under high concurrency or node failures.

How Redis Cluster Works

Redis Cluster distributes data by sharding; each node holds a subset of the 16,384 hash slots. Nodes can be masters or replicas. Masters handle read/write requests, while replicas copy the master’s data to provide redundancy and high availability.

Reasons Write Operations May Be Lost

Asynchronous replication – The master returns to the client before replicas have persisted the write. If the network between master and replica breaks or the master crashes, the write may never be replicated.

Network partitions and node failures – When a node becomes unreachable or a master fails, writes that have not been synced to a replica can be lost, especially if the client reconnects to a different node.

Persistence configuration – Redis provides RDB snapshots and AOF logging. Without AOF or with an unsuitable RDB schedule, a crash can cause recent writes to disappear.

Client does not receive confirmation – If the client’s write request times out or the connection drops before the cluster acknowledges the operation, the write may be lost.

How to Prevent Write Loss

Enable AOF persistence with appendfsync always so every write is flushed to disk (at the cost of some performance).

Use Redis Sentinel or the built‑in high‑availability features of Redis Cluster to monitor masters and perform automatic failover.

Configure replication‑acknowledgement parameters such as min‑slaves‑to‑write and min‑slaves‑max‑lag to require a minimum number of replicas to confirm a write before it is accepted.

Strengthen client‑side error handling: implement retry logic for failed writes and handle exceptions gracefully.

Java Example Using JedisCluster

The following code shows how to create a JedisCluster instance, write a key/value pair, read it back, and handle possible exceptions.

import redis.clients.jedis.JedisCluster;
import redis.clients.jedis.HostAndPort;
import java.util.HashSet;
import java.util.Set;

public class RedisClusterWriteOperation {
    public static void main(String[] args) {
        // Create Redis cluster node set
        Set<HostAndPort> nodes = new HashSet<>();
        nodes.add(new HostAndPort("127.0.0.1", 7000));
        nodes.add(new HostAndPort("127.0.0.1", 7001));
        nodes.add(new HostAndPort("127.0.0.1", 7002));

        // Create JedisCluster instance
        JedisCluster jedisCluster = new JedisCluster(nodes);

        try {
            // Write data to the cluster
            String key = "user:1001";
            String value = "John Doe";
            jedisCluster.set(key, value);

            // Verify write
            String retrievedValue = jedisCluster.get(key);
            System.out.println("Retrieved value: " + retrievedValue);
        } catch (Exception e) {
            System.out.println("Write operation failed: " + e.getMessage());
        } finally {
            try {
                jedisCluster.close();
            } catch (Exception e) {
                System.out.println("Error closing JedisCluster: " + e.getMessage());
            }
        }
    }
}

Conclusion

Write loss is a potential risk in Redis Cluster, especially during network partitions, node failures, or because of asynchronous replication. By enabling appropriate persistence, using high‑availability mechanisms, configuring replication acknowledgments, and adding robust client‑side error handling, the risk can be significantly reduced.