RC: Redis hashing policy

content/operate/rc/databases/configuration/clustering.md

@@ -38,7 +38,7 @@ Redis server.
 An instance that belongs to a cluster can manage multiple hash
 slots. This division of the key space, known as _sharding_, is achieved by
 hashing the key names, or parts of these (key hash tags), in order to
-obtain the hash slot in which a key should reside.
+obtain the hash slot in which a key should reside. Redis Cloud supports several [hashing policies](#manage-the-hashing-policy).
 
 Even when using multiple Redis processes, the use of a Redis
 Enterprise Cloud cluster is nearly transparent to the application that
@@ -86,46 +86,69 @@ are supported, with the following limitations:
     and pipelining are supported with Redis Cloud cluster
     like if it were a non-cluster DB.
 
-## Manage the hashing policy
+## Hashing policies and hash tags {#manage-the-hashing-policy}
 
-Redis defaults to the [standard hashing policy](#standard-hashing-policy). 
-The clustering configuration of a Redis Cloud instance can be changed. 
-However, hashing policy changes delete existing data 
+The hashing policy determines how data is distributed across multiple Redis processes of a database. It uses a hashing function to map keys to hash slots in these processes, ensuring an even distribution of data for optimal performance and scalability.
+
+The hashing function uses the entire key name to calculate the hash slot, unless the key name contains a **hash tag**, represented by a `{...}` pattern.
+
+If the key contains a `{...}` pattern, only the substring between `{` and `}` is hashed in order to obtain the hash slot.
+
+You can use the `{...}` pattern to direct related keys to the same hash slot, so that multi-key operations are supported on them. On the other hand, not using a hashtag in the key's name results in a (statistically) even distribution of keys across the keyspace's shards, which improves resource utilization. If your application does not perform multi-key operations, you don't need to construct key names with hashtags.
+
+Redis Cloud offers 3 hashing policies, which differ in the way hash-tags are processed. Redis defaults to the [standard hashing policy](#standard-hashing-policy). 
+
+{{< warning >}}
+You can change the hashing policy after you create your database. However, hashing policy changes delete existing data 
 (FLUSHDB) before they're applied. 
 
 These changes include:
 
-1. Changing the hashing policy, either from standard to custom or vice versa.
+1. Changing the hashing policy.
 1. Changing the order of custom hashing policy rules.
 1. Adding rules before existing ones in the custom hashing policy.
 1. Deleting rules from the custom hashing policy.
 1. Disabling clustering for the database.
+{{< /warning >}}
+
+### Redis hashing policy
+
+{{< note >}}
+This policy is available for selected accounts and will be rolled out gradually to other accounts in the future.
+{{< /note >}}
+
+The Redis hashing policy is identical to the [hashing policy used by Redis Community Edition]({{< relref "/operate/oss_and_stack/reference/cluster-spec#hash-tags" >}}). This policy is recommended for most users and should be selected if any of the following conditions apply:
+- This is your first Redis Cloud account, and you are starting fresh.
+- You are migrating data from Redis Community Edition or other Redis-managed platforms.
+- Your application does not use hashtags in database key names.
+- Your application uses binary data as key names.
 
 ### Standard hashing policy
 
-When using the standard hashing policy, a Redis Cloud cluster
-behaves like a standard Redis cluster, and hashing is
-performed as follows:
-
-1. Keys with a hashtag: a key's hashtag is any substring between '{'
-    and '}' in the key's name. That means that when a key's name
-    includes the pattern '{...}', the hashtag is used as input for the
-    hashing function. For example, the following key names have the same
-    hashtag and are mapped to the same slot: foo{bar},
-    {bar}baz & foo{bar}baz.
-1. Keys without a hashtag: when a key doesn't contain the '{...}'
-    pattern, the entire key's name is used for hashing.
-
-You can use the '{...}' pattern to direct related keys to the same hash
-slot, so that multi-key operations are supported on them. On the other
-hand, not using a hashtag in the key's name results in a
-(statistically) even distribution of keys across the keyspace's shards, 
-which improves resource utilization. 
-If your application does not perform multi-key operations, you don't
-need to construct key names with hashtags.
+The Standard hashing policy is mostly consistent with the Redis hashing policy, and will generate the same hash-slot calculation in the following cases:
+1. Keys with a single hashtag: a key's hashtag is any substring between '{' and '}' in the key's name. That means that when a key's name includes the pattern '{...}', the hashtag is used as input for the hashing function. For example, the following key names have the same hashtag and are mapped to the same slot: foo{bar}, {bar}baz & foo{bar}baz.
+1. Keys without a hashtag: when a key doesn't contain the '{...}' pattern, the entire key's name is used for hashing
+
+However, this policy is less recommended and should be selected only if any of the following conditions apply:
+- Your application uses empty hashtags to hash different keys to the same hashslot
+- Your application uses multiple curly brackets within a key’s name
+
+In some cases, the Standard hashing policy behaves differently from the Redis hashing policy:
+1. Using empty hashtags (“{}”): the Standard hashing policy does not ignore empty hashtags, so 2 keys which start with empty hashtags will be hashed to the same hashslot (while the Redis hashing policy would ignore them). 
+    For example: given 2 keys {}foo and {}bar, hashing would be:
+    - Standard hashing policy: to the same hash slot
+    - Redis hashing policy: to different hash slots
+2. Using multiple curly brackets: when a key’s name contains multiple curly brackets, the Standard hashing calculation might be different than the Redis hashing policy. 
+    For example: given 2 keys {foo}bar} and {foo}qux}:
+    - Standard hashing policy: substrings “foo}bar” and “foo}qux” will be used for the 1st and 2nd key respectively, hashed each key to a different hash-slot.
+    - Redis hashing policy: the substring “foo” will be used for both keys, hashing them to the same slot.
 
 ### Custom hashing policy
 
+{{< note >}}
+The custom hashing policy is not recommended and will be deprecated in the future. Select this option only if you are already using a custom hashing policy with your existing Redis Cloud databases.
+{{< /note >}}
+
 A Redis Cloud  cluster can be configured to use a custom hashing
 policy. A custom hashing policy is required when different keys need to
 be kept together on the same shard to allow multi-key operations. Redis