DOC-3091 DOC-3752 RS: Fix terms in WAIT docs & mention WAITAOF

Author: rrelledge

content/operate/rs/clusters/optimize/wait.md

@@ -1,62 +1,56 @@
 ---
-Title: Use the WAIT command for strong consistency
+Title: Use the WAIT command to improve data safety and durability
 alwaysopen: false
 categories:
 - docs
 - operate
 - rs
 description: Use the wait command to take full advantage of Redis Enterprise Software's
-  replication based durability.
+  replication-based durability.
 linkTitle: WAIT command
 weight: $weight
 ---
 Redis Enterprise Software comes with the ability to replicate data
 to another replica for high availability and persist in-memory data on
-disk permanently for durability. With the WAIT command, you can
+disk permanently for durability. With the [`WAIT`]({{<relref "/commands/wait">}}) command, you can
 control the consistency and durability guarantees for the replicated and
 persisted database.
 
-Any updates that are issued to the database are typically performed with
-the following flow shown below;
+## Non-blocking Redis write operation
 
-1. Application issues a write,
-1. Proxy communicates with the correct master "shard" in the system
-    that contains the given key,
-1. The acknowledgment is sent to proxy once the write operation
-    completes
+Any updates that are issued to the database are typically performed with the following flow:
+
+1. Application issues a write.
+1. Proxy communicates with the correct primary shard in the system that contains the given key.
+1. The acknowledgment is sent to proxy after the write operation completes.
 1. The proxy sends the acknowledgment back to the application.
 
-Independently, the write is communicated from master to replica and
-replication acknowledges the write back to the master. These are steps 5
-and 6.
+Independently, the write is communicated from the primary shard to the replica, and
+replication acknowledges the write back to the primary shard. These are steps 5 and 6.
 
 Independently, the write to a replica is also persisted to disk and
 acknowledged within the replica. These are steps 7 and 8.
 
 {{< image filename="/images/rs/weak-consistency.png" >}}
 
-With the WAIT command, applications can ask to wait for
+## Blocking write operation on replication
+
+With the `WAIT` command, applications can ask to wait for
 acknowledgments only after replication or persistence is confirmed on
-the replica. The flow of a write operation with the WAIT command is
-shown below:
-
-1. Application issues a write,
-1. Proxy communicates with the correct master "shard" in the system
-    that contains the given key,
-1. Replication communicated the update to the replica shard.
-1. Replica persists the update to disk (assuming AOF every write setting
-    is selected).
-1. The acknowledgment is sent back from the replica all the way to the
-    proxy with steps 5 to 8.
+the replica. The flow of a write operation with the WAIT command is:
+
+1. The application issues a write,
+1. The proxy communicates with the correct primary shard in the system that contains the given key,
+1. Replication communicates the update to the replica shard.
+1. The replica persists the update to disk if the AOF every write setting is selected.
+1. The acknowledgment is sent back from the replica all the way to the proxy with steps 5 to 8.
 
 With this flow, the application only gets the acknowledgment from the
 write after durability is achieved with replication to the replica and to
 the persistent storage.
 
 {{< image filename="/images/rs/strong-consistency.png" >}}
 
-With the WAIT command, applications can have a guarantee that even under
-a node failure or node restart, an acknowledged write is recorded.
+The `WAIT` command always returns the number of replicas that acknowledged the write commands sent by the current client before the `WAIT` command, both in the case where the specified number of replicas are reached, or when the timeout is reached. In Redis Enterprise Software, the number of replicas is always 1 for databases with high availability enabled.
 
-See the WAIT command for details on the new durability and
-consistency options.
+See the [`WAITAOF`]({{<relref "/commands/waitaof">}}) command for details for enhanced data safety and durability capabilities introduced with Redis 7.2.

content/operate/rs/databases/durability-ha/consistency.md

@@ -5,50 +5,49 @@ categories:
 - docs
 - operate
 - rs
-description: Explains the order write operations are communicated from app to proxy
-  to shards for both the weak consistency model and the strong consistency model.
+description: Explains the order write operations are communicated from app to proxy to shards for both non-blocking Redis write operations and blocking write operations on replication.
 linkTitle: Consistency
 weight: 20
 ---
 Redis Enterprise Software comes with the ability to replicate data
 to another database instance for high availability and persist in-memory data on
-disk permanently for durability. With the WAIT command, you can
+disk permanently for durability. With the [`WAIT`]({{<relref "/commands/wait">}}) command, you can
 control the consistency and durability guarantees for the replicated and
 persisted database.
 
-Any updates that are issued to the database are typically performed with
-the following flow shown below;
+## Non-blocking Redis write operation
 
-1. Application issues a write
-2. Proxy communicates with the correct primary (also known as master) "shard" in the system that contains the given key
-3. The shard writes the data and sends an acknowledgment to the proxy
-4. The proxy sends the acknowledgment back to the application
-5. The write is communicated from master to replica
-6. Replica acknowledges the write back to the master
-7. The write to a replica is persisted to disk
-8. The write is acknowledged within the replica
+Any updates that are issued to the database are typically performed with the following flow:
+
+1. The application issues a write.
+2. The proxy communicates with the correct primary (also known as master) shard in the system that contains the given key.
+3. The shard writes the data and sends an acknowledgment to the proxy.
+4. The proxy sends the acknowledgment back to the application.
+5. The write is communicated from the primary shard to the replica.
+6. The replica acknowledges the write back to the primary shard.
+7. The write to a replica is persisted to disk.
+8. The write is acknowledged within the replica.
 
 {{< image filename="/images/rs/weak-consistency.png" >}}
 
-With the WAIT command, applications can ask to wait for
+## Blocking write operation on replication
+
+With the `WAIT` command, applications can ask to wait for
 acknowledgments only after replication or persistence is confirmed on
-the replica. The flow of a write operation with the WAIT command is
-shown below:
+the replica. The flow of a write operation with the `WAIT` command is:
 
-1. Application issues a write,
-2. Proxy communicates with the correct master "shard" in the system that contains the given key,
-3. Replication communicated the update to the replica shard.
-4. Replica persists the update to disk (assuming AOF every write setting is selected).
-5-8. The acknowledgment is sent back from the replica all the way to the proxy with steps 5 to 8.
+1. The application issues a write.
+2. The proxy communicates with the correct primary shard in the system that contains the given key.
+3. Replication communicates the update to the replica shard.
+4. The replica persists the update to disk if the AOF every write setting is selected.
+5. The acknowledgment is sent back from the replica all the way to the proxy with steps 5 to 8.
 
 With this flow, the application only gets the acknowledgment from the
 write after durability is achieved with replication to the replica and to
 the persistent storage.
 
 {{< image filename="/images/rs/strong-consistency.png" >}}
 
-With the WAIT command, applications can have a guarantee that even under
-a node failure or node restart, an acknowledged write is recorded.
+The `WAIT` command always returns the number of replicas that acknowledged the write commands sent by the current client before the `WAIT` command, both in the case where the specified number of replicas are reached, or when the timeout is reached. In Redis Enterprise Software, the number of replicas for HA enabled databases is always 1.
 
-See the WAIT command for details on the new durability and
-consistency options.
+See the [`WAITAOF`]({{<relref "/commands/waitaof">}}) command for details for enhanced data safety and durability capabilities introduced with Redis 7.2.