www.samdhar.com › distributed-mind-blog › when-not-to-use-redis

### 1. Consistency Issues #### Relaxed Consistency Guarantees Redis implements asynchronous replication by design, introducing potential consistency gaps between master and replica nodes. During normal operations, these inconsistencies may be negligible, but they become particularly significant during failover scenarios. When a master node fails and a replica is promoted, the recovered system state may not reflect the most recent transactions, potentially compromising data integrity and application consistency. #### Split-Brain Scenarios Network partitions present a particular challenge for Redis clusters. In these scenarios, nodes may experience communication disruptions that lead to multiple nodes simultaneously assuming the master role. This "split-brain" condition results in divergent write operations and data inconsistencies across the cluster, requiring careful monitoring and resolution protocols. ### 2. Data Loss Risks #### Incomplete Propagation The asynchronous replication model introduces a vulnerability window where committed writes may not have propagated to replica nodes. During failover events, these uncommitted transactions can be permanently lost, potentially impacting system reliability and data durability guarantees. … ### 3. Potential for Higher Failover Latency Redis employs a gossip protocol and majority voting mechanism for failure detection and master election, contrasting with the formal consensus algorithms (such as Raft or Paxos) used by other distributed systems. While this approach reduces implementation complexity, it can introduce increased latency during failover operations compared to consensus-driven architectures. ### 4. Lack of Strong Consistency #### Transactions Across Nodes A significant limitation of Redis Cluster is its inability to execute multi-key transactions when keys are distributed across different nodes. This architectural constraint can substantially impact applications requiring atomic operations across multiple keys, necessitating careful key distribution strategies or alternative solutions. #### Atomic Guarantees Redis provides limited guarantees for atomic writes in distributed scenarios, particularly during replication and failover events. This limitation can significantly impact applications requiring strict transactional integrity, especially in financial or mission-critical systems. … ### Conclusion Redis's architectural decisions reflect a deliberate prioritization of performance and operational simplicity over strong consistency guarantees. While this makes Redis an excellent choice for specific use cases, particularly those prioritizing low latency and high throughput, it introduces notable trade-offs in data consistency and reliability. When evaluating Redis for your architecture, carefully assess your system's requirements against these trade-offs. For applications demanding strong consistency guarantees and robust fault tolerance, consider consensus-based alternatives like etcd or Zookeeper, which provide stronger consistency guarantees at the cost of increased complexity and latency.