Three Ways to Fail Over: LoadBalancer, Sentinel, and Cluster 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.