Introduction to Redis Software

Redis Software is a self-managed, enterprise-grade version of Redis designed for organizations that need scalability, high availability, and predictable performance. It offers features like linear scaling, automated backups and recovery, and 24/7 support. Redis Software can be deployed on-prem or in your preferred cloud environment. The platform is architected around key building blocks—including nodes, clusters, cluster quorum, the cluster manager, shards, databases and endpoints, and proxies—to deliver speed, resilience, and flexibility for mission-critical workloads. To understand how these components function together in a distributed system, see Redis Enterprise as a Distributed System.

Key Concepts and Architecture

Node A node is the base unit of a Redis cluster. It can be a physical machine, virtual machine, or container running Redis Software. Each node may host databases, the cluster manager, and proxies.

Cluster A Redis Cluster consists of multiple nodes connected on a local network. Clusters are designed for scalability, high availability, and shared-nothing architecture.

Cluster Symmetry:

• All nodes run the same core services
• All nodes can host master and replica shards
• Typically, nodes have identical hardware specs (except quorum-only nodes)

Shared-Nothing Architecture:

• No shared CPU, memory, or storage resources
• Eliminates single points of failure

High-Availability Configurations:

• 99.9%: Local replication (master + replica in same cluster)
• 99.99%: Replication with rack-zone awareness
• 99.999%: Replication, rack-zone awareness, and Active-Active Geo Distribution
• Requires an odd number of nodes (minimum 3) for quorum
• Quorum-only nodes (QO-nodes) can provide quorum without being full-sized data nodes

Cluster Manager

Each Redis node runs an instance of the cluster manager, a core component responsible for maintaining the health and coordination of the cluster. A Redis cluster requires a minimum of 3 nodes to ensure quorum, with one node acting as the Master of the Cluster to oversee cluster-level operations.

The cluster manager handles key responsibilities such as, but isn't limited to:

• Making cluster health-related decisions

• Managing shard creation, placement, migration, and re-sharding

• Handling provisioning and deprovisioning requests

• Overseeing resource management, statistics, and monitoring

Cluster Quorum

A cluster quorum is the minimum number of Redis nodes that must be available for the cluster to remain operational. Quorum is achieved when more than 50% of the nodes are online—for example, 2 out of 3 nodes or 3 out of 5. Redis clusters must have an odd number of nodes, with a minimum of 3, to reliably support high availability and withstand process failure, node failure, and network splits.

At any given time, one node is designated as the master node. The master is responsible for cluster-wide decisions, including:

• Monitoring cluster health

• Orchestrating shard migrations between nodes

• Handling database create/update/delete operations

• Collecting cluster statistics

• Managing alerts and backups

This architecture ensures that the cluster can make consistent decisions even during partial failures.

Redis 8 Database Capabilities (Version-Specific)

• 8.0.2-17 and Later (Redis 8.x Databases)
  Beginning with Redis Software 8.0.2-17, database capabilities such as Search & Query, JSON, Time Series, and Probabilistic are built into the database version and automatically enabled based on database type (RAM-only, Flash-enabled, or Active-Active).

  • No manual module selection or “add a module” step is required during database creation.

  • Capabilities are provisioned automatically according to the database type and deployment mode.

  • For a detailed breakdown, see the Database Creation table in Redis Software documentation.

• Earlier Versions (≤7.8–7.22 / ≤7.4)
  Continue using the Modules picker during database creation. Capabilities are provided through explicitly added modules rather than built-in functionality.

See the Redis 8.0.2-17 Release Notes for more details.

Shard

A shard in Redis is an instance that stores a partition of a database. Each shard can act as either a master or a replica, and every node in the cluster can host multiple shards.

Redis supports several database configurations built from shards:

• Standard Redis database: A single shard without replication or clustering.

• Highly available Redis database: A master shard with a replica shard placed on a separate node for automatic failover.

• Clustered Redis database: Data is split across multiple master shards for scalability, with intelligent algorithms managing shard placement and migration.

• Clustered and highly available Redis database: Each master shard has a replica shard on a different node to ensure high availability and fault tolerance.

This architecture enables Redis to scale horizontally while maintaining high-performance, availability, and resilience.

Database & Database Endpoint

A Redis database is a container for data, accessible via a dedicated database endpoint managed by the cluster’s proxy layer.

Each Redis database includes:

• At least one master shard

  • Optionally includes one or more replica shards for high availability

• Support for multiple deployment configurations:

  • Standalone – Single Redis shard (no replication or clustering)

  • High Availability (HA) – One master shard with a replica on a separate node

  • Clustered – Data distributed across multiple master shards for scalability

  • Clustered + HA – Clustered setup with a replica for each master shard

• Custom configuration and access control

  • Database-level settings allow for tailored performance and security

• Flexible shard placement

  • Shards can be distributed across nodes for optimal performance and fault tolerance

The database endpoint routes Redis commands to the appropriate shard(s). It automatically updates to reflect failover events:

• If a master shard fails, the endpoint updates to point to the promoted replica

• If an endpoint fails, the replica endpoint is promoted

• In clustered databases, a single endpoint manages routing across all master shards

This setup ensures seamless operation, even during failover, without requiring client-side awareness of the shard topology.

Proxy

Each Redis node includes a high-performance, zero-latency, multi-threaded proxy that routes client operations to the correct database shard. It abstracts the complexity of distributed architecture by:

• Forwarding client requests to the appropriate shard (master or replica)

• Providing database endpoints

• Supporting Redis RESP and Memcached protocols

• Implemented in C++ for maximum performance

The proxy enables the use of standard Redis clients while optimizing performance through techniques like automatic pipelining, even when not explicitly requested by the client.

Redis Software as a Distributed System

Redis Software is designed as a distributed system, meaning it runs across multiple independent nodes that work together as a single, high-performing cluster. This design provides scalability, high availability, and fault tolerance—but also introduces complexity that Redis Software solves for you.

Key design considerations include:

• Cluster quorum and master election to ensure high availability

• Shard distribution and replication for performance and fault tolerance

• Active-Active replication (CRDB) for globally distributed workloads

• Shared-nothing architecture to eliminate single points of failure

For a deep dive into how Redis handles consistency, node failures, and cross-cluster synchronization, see: Troubleshooting Distributed System Issues in Redis

Onboarding Progress

Previous: This is the first step
Next: System and Infrastructure Requirements

Return to the Redis Software Onboarding Overview to view all steps.