I have to admit the diagram is a bit misleading. The core idea here is called chunk: https://github.com/doyoubi/undermoon/blob/master/docs/chunk.md https://git

I have to admit the diagram is a bit misleading. The core idea here is called chunk: https://github.com/doyoubi/undermoon/blob/master/docs/chunk.md https://github.com/doyoubi/undermoon/blob/master/docs/chunk.... Each proxy always runs in front of 2 Redis instances. Each chunk consists of 2 proxies and thus 4 Redis instances on 2 different physical servers. And each Redis has its master/replica on another half part under another proxy inside the chunk. So master and replica are always not in the same physical server. Chunk is the smallest building block of a cluster so the Redis instances number is always a multiple of 4. We designed it in this way because we came up with an algorithm to balance the overall workload based on this chunk structure: https://github.com/doyoubi/undermoon/blob/master/docs/chunk_allocation.txt https://github.com/doyoubi/undermoon/blob/master/docs/chunk_... For the second question, the proxy here is just a way to add additional features on the top of Redis without changing its source code. I would say it's a server-side proxy while envoy focuses on the client-side features. And yes, it can handle failover transparently for clients. In Kubernetes, the metadata is stored inside a ConfigMap, which is based on etcd.