removed misleading sentence, fixed italics

Author: flang-msft

articles/azure-cache-for-redis/cache-high-availability.md

@@ -2,6 +2,7 @@
 title: High availability for Azure Cache for Redis
 description: Learn about Azure Cache for Redis high availability features and options
 author: flang-msft
+
 ms.service: cache
 ms.topic: conceptual
 ms.date: 03/29/2022
@@ -12,7 +13,7 @@ ms.author: franlanglois
 
 As with any cloud systems, unplanned outages can occur that result in a virtual machines (VM) instance, an Availability Zone, or a complete Azure region going down. We recommend customers have a plan in place to handle zone or regional outages.
 
-This article presents the information for customers to create a *business continuity and disaster recovery plan* for their Azure Cache for Redis, or Azure Cache for Redis Enterprise implementation.
+This article presents the information for customers to create a _business continuity and disaster recovery plan_ for their Azure Cache for Redis, or Azure Cache for Redis Enterprise implementation.
 
 Various high availability options are available in the Standard, Premium, and Enterprise tiers:
 
@@ -32,7 +33,7 @@ Azure Cache for Redis, in the Standard or Premium tier, has a high availability
 
 An Azure Cache for Redis in the Standard or Premium tier runs on a pair of Redis servers by default. The two servers are hosted on dedicated VMs. Open-source Redis allows only one server to handle data write requests.
 
-With Azure Cache for Redis, one server is the *primary* node, while the other is the *replica*. After it provisions the server nodes, Azure Cache for Redis assigns primary and replica roles to them. The primary node usually is responsible for servicing write and read requests from  clients. On a write operation, it commits a new key and a key update to its internal memory and replies immediately to the client. It forwards the operation to the *replica* asynchronously.
+With Azure Cache for Redis, one server is the _primary_ node, while the other is the _replica_. After it provisions the server nodes, Azure Cache for Redis assigns primary and replica roles to them. The primary node usually is responsible for servicing write and read requests from  clients. On a write operation, it commits a new key and a key update to its internal memory and replies immediately to the client. It forwards the operation to the _replica_ asynchronously.
 
 :::image type="content" source="media/cache-high-availability/replication.png" alt-text="Data replication setup":::
 
@@ -41,7 +42,7 @@ With Azure Cache for Redis, one server is the *primary* node, while the other is
 >
 >
 
-If the *primary* node in a cache is unavailable, the *replica* promotes itself to become the new primary automatically. This process is called a *failover*. The replica waits for a sufficiently long time before taking over in case that the primary node recovers quickly. When a failover happens, Azure Cache for Redis provisions a new VM and joins it to the cache as the replica node. The replica does a full data synchronization with the primary so that it has another copy of the cache data.
+If the _primary_ node in a cache is unavailable, the _replica_ promotes itself to become the new primary automatically. This process is called a _failover_. The replica waits for a sufficiently long time before taking over in case that the primary node recovers quickly. The replica does a full data synchronization with the primary so that it has another copy of the cache data.
 
 A primary node can go out of service as part of a planned maintenance activity, such as an update to Redis software or the operating system. It also can stop working because of unplanned events such as failures in underlying hardware, software, or network. [Failover and patching for Azure Cache for Redis](cache-failover.md) provides a detailed explanation on types of failovers. An Azure Cache for Redis goes through many failovers during its lifetime. The design of the high availability architecture makes these changes inside a cache as transparent to its clients as possible.
 
@@ -70,12 +71,12 @@ A zone redundant cache provides automatic failover. When the current primary nod
 
 ### Enterprise and Enterprise Flash tiers
 
-A cache in either Enterprise tier runs on a Redis Enterprise *cluster*. It always requires an odd number of server nodes to form a quorum. By default, it has three nodes, each hosted on a dedicated VM.
+A cache in either Enterprise tier runs on a Redis Enterprise _cluster_. It always requires an odd number of server nodes to form a quorum. By default, it has three nodes, each hosted on a dedicated VM.
 
-- An Enterprise cache has two same-sized *data nodes* and one smaller *quorum node*.
+- An Enterprise cache has two same-sized _data nodes_ and one smaller _quorum node_.
 - An Enterprise Flash cache has three same-sized data nodes.
 
-The Enterprise cluster divides Azure Cache for Redis data into partitions internally. Each partition has a *primary* and at least one *replica*. Each data node holds one or more partitions. The Enterprise cluster ensures that the primary and replica(s) of any partition are never collocated on the same data node. Partitions replicate data asynchronously from primaries to their corresponding replicas.
+The Enterprise cluster divides Azure Cache for Redis data into partitions internally. Each partition has a _primary_ and at least one _replica_. Each data node holds one or more partitions. The Enterprise cluster ensures that the primary and replica(s) of any partition are never collocated on the same data node. Partitions replicate data asynchronously from primaries to their corresponding replicas.
 
 When a data node becomes unavailable or a network split happens, a failover similar to the one described in [Standard replication](#standard-replication-for-high-availability) takes place. The Enterprise cluster uses a quorum-based model to determine which surviving nodes participates in a new quorum. It also promotes replica partitions within these nodes to primaries as needed.