Redis Enterprise puts a proxy in front of its shards, while open-source Redis Cluster expects the client to be cluster-aware. What does that proxy layer actually buy you operationally, and what does it cost?
answer
- client-side slot map vs proxy-side routing
- node = shards + proxy + cluster manager
- database is the unit, not the server; many per cluster
- buys client simplicity + invisible topology change
- costs a hop, a component to size, licence, opacity
basics
~20 sThe proxy gives clients one stable endpoint: it routes to the right shard, so clients need no slot map or redirect handling, and resharding, failover and scaling happen behind it. The cost is an extra network hop, another component to size and make highly available, plus licensing and a more opaque topology.
solid answer
~60 sIn open-source Redis Cluster the client holds the hash-slot map and follows redirects itself, so every client library must implement cluster support correctly. Redis Enterprise inserts a **proxy per node** in front of the shard processes. Clients connect to a single endpoint per database and speak plain Redis; the proxy resolves the key to a shard and forwards it. A separate **cluster manager** watches shards, promotes replicas on failure, and moves shards between nodes. What that buys: - **Client simplicity** — non-cluster-aware clients and libraries work unchanged; no redirect handling in application code. - **Topology changes stay invisible** — resharding, scaling, rebalancing and failover happen behind the endpoint. - **Density and multi-tenancy** — many logical databases, each with its own endpoint, memory limit and policy, on one cluster; plus rack/zone-aware placement. What it costs: an extra hop on every request (small, but real for microsecond-sensitive workloads), a component that itself needs threads, capacity planning and HA, licensing, and less visibility into where a key actually lives. It is an operational trade, not a performance win.
go deeper
Know that Enterprise clients use one endpoint and a proxy routes to shards, while open-source cluster clients route themselves.
Name the three components (shards, proxy, cluster manager) and the database-as-unit model, and state the hop cost.
Argue the trade concretely: client-library heterogeneity and topology-change safety versus an extra hop, a component to size, and licensing.
Position it as buying an operational abstraction rather than performance, and weigh it against the organisation's client-stack diversity and ops capacity.
## Two ways to solve the same problem Any sharded key-value store must answer "which node holds this key?". Open-source Redis Cluster answers it **at the client**: the cluster publishes a map of hash slots to nodes, the client caches it, computes the slot for a key, and connects directly; when the map is stale the node replies with a redirect and the client refreshes. The upside is a direct, single-hop path; the downside is that every client library, in every language your organisation uses, must implement that logic correctly — including redirect handling, map refresh, and the restriction that multi-key commands must stay within one slot. Redis Enterprise answers it **at a proxy**. Each node runs a proxy process that terminates client connections and forwards commands to the right shard, wherever that shard currently lives. Applications connect to a single endpoint per database and can use an ordinary, non-cluster-aware client. ## The components A Redis Enterprise cluster is a set of nodes, each running three kinds of process: - **Shards** — actual Redis processes, each holding a slice of the keyspace. A database is composed of one or more primary shards, each optionally with a replica shard placed on a different node (and, where configured, a different rack or availability zone). - **A proxy** — a multi-threaded process handling client connections and routing. Because it is multi-threaded and separate from the shards, connection handling and protocol parsing scale independently of the single-threaded shard processes. - **A cluster manager** — control plane: health checks, automatic failover (promote a replica shard, repoint the proxy), shard migration, rebalancing, resharding, backups, alerting, and the admin UI/API. The unit of provisioning is a **database**, not a server. One cluster can host many databases, each with its own endpoint, memory quota, eviction policy, persistence setting, replication setting and access control — which is what makes the platform viable for internal multi-tenancy where dozens of teams each want "a Redis". ## What the proxy actually buys **Client compatibility.** The client sees what looks like a single Redis. Legacy applications, libraries without solid cluster support, and tools that assume one endpoint all work. In organisations with a long tail of languages, this alone is often the deciding factor. **Invisible topology change.** Adding shards, rebalancing after a node is added, migrating a shard off a node being drained for maintenance, or promoting a replica after a failure — all of these change where a key lives. Behind a proxy, the client's connection and endpoint do not change; the proxy re-points. In the open-source model, correctness during these transitions depends on the client implementing redirects properly. **Density and placement policy.** The control plane can pack many small databases onto shared nodes, enforce that a primary and its replica never share a node or rack, and rebalance automatically. Doing the equivalent by hand across many self-managed clusters is where a lot of ops time goes. **Operational features attached to the same control plane** — automated backups, in-place upgrades, per-database TLS and ACL configuration, metrics, and support SLAs. ## What it costs **A hop.** Client → proxy → shard is one more network traversal and one more queueing point than client → shard. On a well-provisioned cluster this is tens of microseconds, but for workloads whose entire budget is sub-millisecond it is measurable, and it is why the proxy is not sold as a performance feature. **A component to operate.** The proxy needs CPU and threads sized against connection count and throughput; a misconfigured proxy becomes the bottleneck before any shard does. It also must be highly available, which is why it runs per node with the endpoint resolvable to healthy nodes. **Opacity.** "Which shard is this key on, and is that shard hot?" is a question you answer through the platform's tooling rather than by reasoning about the slot map yourself. Debugging skew still requires understanding key distribution — the proxy hides the routing, not the physics. **Cost and lock-in.** It is commercial software with per-node or per-shard pricing, and its cluster/administration model is not the open-source one, so an exit means re-adopting cluster-aware clients. ## The honest summary for an interview The proxy is not a scalability trick — the shards still do the work and are still single-threaded per shard. It is an **operational abstraction**: it moves the burden of topology awareness from every client in the organisation into one managed layer, and charges you a hop plus a licence for it. Whether that trade is right depends on how many client stacks you own and how much appetite you have to run cluster operations yourself.
- Does the proxy remove the constraint that multi-key commands must touch keys on one shard?No. The shards are still independent Redis processes, so a command spanning keys on different shards has no single place to execute. The proxy can route, not join. You still need hash tags to co-locate related keys, exactly as in open-source Redis Cluster, and cross-shard multi-key operations remain unsupported or restricted.
- If the proxy is multi-threaded, does that mean Redis Enterprise escapes Redis's single-threaded command execution?Only for connection handling and protocol work. Each shard is still a Redis process executing commands one at a time, so a single slow command still blocks its shard. The multi-threaded proxy raises the ceiling on connections and network throughput per node; it does not parallelise the execution of commands within a shard.
Open-source Cluster is like giving every visitor a floor plan and letting them find the right office themselves; Enterprise puts a receptionist at the door who knows where everyone has moved to. Faster for the visitor who already has the plan, far less error-prone for everyone else.
saying these in an interview costs you the question
- Claiming the proxy makes Redis multi-threaded or removes per-shard serialisation
- Believing the proxy allows multi-key commands across shards without hash tags
- Describing Enterprise as 'just managed Redis' with no architectural difference
- Assuming the proxy is free of latency cost because it is local to the node
- Treating a database and a node as the same provisioning unit