In-memory cluster-parameter values on any data-bearing node are always eventually consistent. This means the in-memory state can lag or be 'ahead of' of the majority-committed value for any cluster parameter in the system.

Dedicated routers in-memory parameter state is periodically refreshed via a majority read from config servers. This means that the parameter values strictly lag what is majority-committed on the CSRS, and therefore, on each shard. Note that the router can still route commands to nodes that have different in-memory parameter values, and that the values that getClusterParameter returns on the router can always be stale. But, it provided a snapshot of a value that was majority-committed cluster-wide.

In embedded-router mode, the in-memory cached value is returned via getClusterParameter. This keeps the value returned by the command consistent with the process's own view of the parameter in-memory. But it removes the ability to get an elegant 'snapshot' view. Since ClusterParameters offer an eventually-consistent semantic anyway, we viewed this as an acceptable option. But it may be worth providing this semantic in the future.

Note that if we were to provide this semantic and keep the values it returns synchronized with in-memory values, we would to either partition cluster-parameters (and therefore likely server parameters) between cluster roles