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,11 +86,22 @@ 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 how hash tags are processed. These hashing policies are not always available.
+
+For accounts created after MONTH DAY, 2025, Redis defaults to the [Redis hashing policy](#redis-hashing-policy) **when creating a new database**. For all other accounts, Redis defaults to the [standard hashing policy](#standard-hashing-policy). 
+
+{{< warning >}}
+You can change the hashing policy between Standard and Custom after you create your database. However, hashing policy changes delete existing data 
 (FLUSHDB) before they're applied. 
 
 These changes include:
@@ -100,32 +111,48 @@ These changes include:
 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 available for accounts created after MONTH DAY, 2025.
+
+For all other accounts, this 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