TODO

Cluster Mode/Sharding Issues
============================

## ShardGroup Nodes Round-Robin [DONE]

Currently we always reply with a `-MOVED` pointing to the first node of the
target shard group. Ideally we should round-robin so in case the first node died
clients will still eventually find a different node.

## ShardGroup Convergence and Persistence [DONE]

Currently shard groups configuration is local and ephemeral, but ideally it
should be distributed and persistent, i.e.

1. Whenever we learn something about a remote shardgroup (by means of user
command or gossip-like) it should propagate from the leader to all nodes.
2. Shard group configuration should be persisted (both in log and snapshot).

Essentially this means we need to treat it as we handle nodes configuration,
only this is simpler as no joint consensus is needed.

## ShardGroup Refresh

We need to come up with a basic mechanism to refresh shardgroup configuration.
There is already a `RAFT.SHARDGROUP GET` command so it could be as simple as:

- Every leader periodically polls the shard groups configured.
- It sends a `RAFT.SHARDGROUP GET` request and updates the local configuration
  if anything changed (i.e. new / removed nodes).

---

Other stuff:
* Consider changing config change log format encoding to make it more readable and architecture neutral.
* Clean up snapshot info saving / loading. Maybe revert to AUX fields and rely on hooks?
* Migrate to RedisModule_Assert