Skip to main content

Three Ways to Fail Over: LoadBalancer, Sentinel, and Cluster on the Zaris RESP Front-End

· 6 min read
Clustron Team
Clustron Team
Distributed Systems Engineering

Three ways to fail over on the Zaris RESP front-end

Zaris exposes a Redis-protocol (RESP) front-end so any Redis client, in any language, can point at a Zaris cluster and use it as a drop-in store. But "any Redis client" hides a real problem: Redis client ecosystems do not agree on how to discover topology or how to recover when a node disappears. A plain client expects a single stable endpoint. A Sentinel-based client expects to ask a discovery service "who is the master?" A cluster-mode client expects hash slots and MOVED/ASK redirects.

If a store spoke only one of those dialects, a whole class of clients would be locked out. So the Zaris RESP front-end supports three failover models, each matching how a particular family of Redis clients already expects to work. You pick the model per deployment; the client behaves exactly as it would against real Redis.

One honest note up front, because it shapes everything below: all three models sit in front of the same replicated, partitioned Zaris store. The model you choose changes discovery and redirection semantics — how a client finds a node and what it does when one fails — not where your data actually lives.

One store, three client dialects​

A Zaris cluster is several nodes with partitioned, replicated data. When the node a client is talking to goes down, the client has to find another one and keep going — and Redis clients were written against three different discovery mechanisms:

  • A plain client just opens a connection to a host and port. It has no concept of topology.
  • A Sentinel-aware client treats master discovery as a separate protocol: it queries Sentinel for the current master, connects, and re-queries after a failover.
  • A cluster-mode client fetches a slot map at connect time and routes every key to the node that owns its slot, following MOVED/ASK redirects.

Zaris answers all three. The model is chosen at deployment time with ZARIS_RESP_* environment flags.

Model 1 — LoadBalancer: the simplest drop-in​

Clients connect through a single stable endpoint — a Kubernetes Service or any L4 load balancer — and Zaris routes and redirects internally behind it. Any node accepts any key. When a node dies it drops out of rotation and the next connection lands on a healthy node. This works with any plain Redis client, because it asks nothing beyond "connect to this address," and failover is transparent behind the endpoint.

# One stable endpoint in front of the whole cluster.
redis-cli -h redis.example.com -p 6379 SET user:42 "ada"
redis-cli -h redis.example.com -p 6379 GET user:42
apiVersion: v1
kind: Service
metadata:
  name: zaris-resp
spec:
  type: LoadBalancer
  selector:
    app: zaris
  ports:
    - name: resp
      port: 6379
      targetPort: 6379

Reach for this first: fewest moving parts, widest client support.

Model 2 — Sentinel: for stacks already built around Sentinel​

Plenty of teams already run Redis access through Sentinel-aware clients, configured with Sentinel addresses and a master name. So Zaris answers the Redis Sentinel protocol: the client asks "who is the master?", Zaris tells it, and the client connects to that node. On a failover, the client re-resolves through the same code path it already uses and reconnects. Nothing about the client's failover logic changes.

redis-cli -h zaris-sentinel.example.com -p 26379 \
  SENTINEL get-master-addr-by-name zaris-primary

Choose this when your stack is already Sentinel-based.

Model 3 — Cluster: CRC16 slot-aligned​

For clients that speak the Redis Cluster protocol, Zaris answers CLUSTER SLOTS and CLUSTER NODES and issues MOVED/ASK redirects with CRC16 hash-slot-aligned routing — the same CRC16(key) % 16384 slot math a Redis Cluster client uses. Because Zaris's internal routing and the Redis slot math are aligned, the client's idea of which slot a key belongs to matches Zaris's own placement, so it routes each key directly to the owning node.

That makes redis-cli --cluster and cluster-mode libraries a drop-in. During a rebalance or failover, ownership of a slot moves and the node answers with a redirect; the client refreshes its slot map and follows along.

redis-cli -c -h 10.0.0.10 -p 6379 SET user:42 "ada"
redis-cli -h 10.0.0.10 -p 6379 CLUSTER SLOTS

Pick this when you run cluster-mode clients, or want client-side slot awareness so clients route directly to owners.

Tested under kill and rejoin​

All three models were validated under node kill followed by rejoin. In each, clients recover — the LoadBalancer client reconnects through the endpoint, the Sentinel client re-resolves the master, and the cluster client refreshes its slot map — and traffic continues against the surviving nodes. A failover model that has not been exercised under real node loss is a guess.

Selecting a model​

The model is a per-deployment choice, set through ZARIS_RESP_* flags:

env:
  - name: ZARIS_RESP_ENABLED
    value: "true"
  - name: ZARIS_RESP_FAILOVER_MODEL
    value: "cluster"   # or "loadbalancer" / "sentinel"

The decision guide​

  • LoadBalancer for the simplest drop-in. Works with any plain Redis client, hides failover behind one endpoint. Start here unless you have a reason not to.
  • Sentinel when your stack is already built around Sentinel — clients keep their existing master-discovery and failover code.
  • Cluster when you run cluster-mode clients, or want client-side slot awareness so clients route directly to the owning node and follow redirects during rebalancing and failover.

The honest boundary​

All three models front the same replicated, partitioned Zaris store. Whichever you choose, your data is placed and replicated the same way underneath — the model changes only how clients discover nodes and redirect on failure, not the durability or placement of the data. It is a client-compatibility decision layered on top of one consistent store.

For the routing internals — how CRC16 alignment lets cluster clients reach owners without a proxy — see how Zaris speaks the Redis protocol.