1 files changed, 44 insertions, 22 deletions

diff --git a/doc/development/redis/new_redis_instance.md b/doc/development/redis/new_redis_instance.md
index 0a030a0877f..00cc102b427 100644
--- a/doc/development/redis/new_redis_instance.md
+++ b/doc/development/redis/new_redis_instance.md
@@ -119,7 +119,7 @@ Migration Requirements:
 
 - No downtime.
 - No loss of stored data until the TTL for storing data expires.
-- Partial rollout using Feature Flags or ENV vars or combinations of both.
+- Partial rollout using feature flags or ENV vars or combinations of both.
 - Monitoring of the switch.
 - Prometheus metrics in place.
 - Easy rollback without downtime in case the new instance or logic does not behave as expected.
@@ -177,19 +177,15 @@ bin/feature-flag use_primary_store_as_default_for_foo
 ```
 
 By enabling `use_primary_and_secondary_stores_for_foo` feature flag, our `Gitlab::Redis::Foo` will use `MultiStore` to write to both new Redis instance
-and the [old (fallback-instance)](#fallback-instance).
-If we fail to fetch data from the new instance, we will fallback and read from the old Redis instance.
-We can monitor logs for `Gitlab::Redis::MultiStore::ReadFromPrimaryError`, and also the Prometheus counter `gitlab_redis_multi_store_read_fallback_total`.
+and the [old (fallback-instance)](#fallback-instance). All read commands are performed only on the default store which is controlled using the
+`use_primary_store_as_default_for_foo` feature flag. By enabling `use_primary_store_as_default_for_foo` feature flag,
+the `MultiStore` uses `primary_store` (new instance) as default Redis store.
 
 For `pipelined` commands (`pipelined` and `multi`), we execute the entire operation in both stores and then compare the results. If they differ, we emit a
 `Gitlab::Redis::MultiStore:PipelinedDiffError` error, and track it in the `gitlab_redis_multi_store_pipelined_diff_error_total` Prometheus counter.
 
-Once we stop seeing those errors, this means that we are no longer relying on the data stored on the old Redis store.
-At this point, we are probably safe to move the traffic to the new Redis store.
-
-By enabling `use_primary_store_as_default_for_foo` feature flag, the `MultiStore` will use `primary_store` (new instance) as default Redis store.
-
-Once this feature flag is enabled, we can disable `use_primary_and_secondary_stores_for_foo` feature flag.
+After a period of time for the new store to be populated, we can perform external validation to compare the state of both stores.
+Upon satisfactory validation results, we are probably safe to move the traffic to the new Redis store. We can disable `use_primary_and_secondary_stores_for_foo` feature flag.
 This will allow the MultiStore to read and write only from the primary Redis store (new store), moving all the traffic to the new Redis store.
 
 Once we have moved all our traffic to the primary store, our data migration is complete.
@@ -206,17 +202,44 @@ MultiStore implements read and write Redis commands separately.
 - `smembers`
 - `scard`
 
+- 'exists'
+- 'exists?'
+- 'get'
+- 'hexists'
+- 'hget'
+- 'hgetall'
+- 'hlen'
+- 'hmget'
+- 'hscan_each'
+- 'mapped_hmget'
+- 'mget'
+- 'scan_each'
+- 'scard'
+- 'sismember'
+- 'smembers'
+- 'sscan'
+- 'sscan_each'
+- 'ttl'
+- 'zscan_each'
+
 ##### Write commands
 
-- `set`
-- `setnx`
-- `setex`
-- `sadd`
-- `srem`
-- `del`
-- `pipelined`
-- `flushdb`
-- `rpush`
+- 'del'
+- 'eval'
+- 'expire'
+- 'flushdb'
+- 'hdel'
+- 'hset'
+- 'incr'
+- 'incrby'
+- 'mapped_hmset'
+- 'rpush'
+- 'sadd'
+- 'set'
+- 'setex'
+- 'setnx'
+- 'srem'
+- 'unlink'
 
 ##### `pipelined` commands
 
@@ -227,7 +250,8 @@ Thus, excluding the Redis operations performed, the block should be idempotent.
 - `multi`
 
 When a command outside of the supported list is used, `method_missing` will pass it to the old Redis instance and keep track of it.
-This ensures that anything unexpected behaves like it would before.
+This ensures that anything unexpected behaves like it would before. In development or test environment, an error would be raised for early
+detection.
 
 NOTE:
 By tracking `gitlab_redis_multi_store_method_missing_total` counter and `Gitlab::Redis::MultiStore::MethodMissingError`,
@@ -237,7 +261,6 @@ a developer will need to add an implementation for missing Redis commands before
 
 | error                                             | message                                                                                     |
 |---------------------------------------------------|---------------------------------------------------------------------------------------------|
-| `Gitlab::Redis::MultiStore::ReadFromPrimaryError` | Value not found on the Redis primary store. Read from the Redis secondary store successful. |
 | `Gitlab::Redis::MultiStore::PipelinedDiffError`   | `pipelined` command executed on both stores successfully but results differ between them.   |
 | `Gitlab::Redis::MultiStore::MethodMissingError`   | Method missing. Falling back to execute method on the Redis secondary store.                |
 
@@ -245,7 +268,6 @@ a developer will need to add an implementation for missing Redis commands before
 
 | Metrics name                                          | Type               | Labels                     | Description                                              |
 |-------------------------------------------------------|--------------------|----------------------------|----------------------------------------------------------|
-| `gitlab_redis_multi_store_read_fallback_total`        | Prometheus Counter | `command`, `instance_name` | Client side Redis MultiStore reading fallback total      |
 | `gitlab_redis_multi_store_pipelined_diff_error_total` | Prometheus Counter | `command`, `instance_name` | Redis MultiStore `pipelined` command diff between stores |
 | `gitlab_redis_multi_store_method_missing_total`       | Prometheus Counter | `command`, `instance_name` | Client side Redis MultiStore method missing total        |