Merge pull request #270950 from spelluru/sbusissues0401

Fixing feedback issues

Author: prmerger-automator[bot]

articles/service-bus-messaging/service-bus-outages-disasters.md

@@ -2,7 +2,7 @@
 title: Insulate Azure Service Bus applications against outages and disasters
 description: This article provides techniques to protect applications against a potential Azure Service Bus outage.
 ms.topic: article
-ms.date: 12/15/2022
+ms.date: 04/02/2024
 ---
 
 # Best practices for insulating applications against Service Bus outages and disasters
@@ -11,7 +11,7 @@ Mission-critical applications must operate continuously, even in the presence of
 
 An outage is defined as the temporary unavailability of Azure Service Bus. The outage can affect some components of Service Bus, such as a messaging store, or even the entire datacenter. After the problem has been fixed, Service Bus becomes available again. Typically, an outage doesn't cause loss of messages or other data. An example of a component failure is the unavailability of a particular messaging store. An example of a datacenter-wide outage is a power failure of the datacenter, or a faulty datacenter network switch. An outage can last from a few minutes to a few days.
 
-A disaster is defined as the permanent loss of a Service Bus scale unit or datacenter. The datacenter may or may not become available again. Typically a disaster causes loss of some or all messages or other data. Examples of disasters are fire, flooding, or earthquake.
+A disaster is defined as the permanent loss of a Service Bus scale unit or datacenter. The datacenter might or might not become available again. Typically a disaster causes loss of some or all messages or other data. Examples of disasters are fire, flooding, or earthquake.
 
 ## Protection against outages and disasters - premium tier
 High availability and disaster recovery concepts are built right into the Azure Service Bus **premium** tier, both within the same region (via availability zones) and across different regions (via geo-disaster Recovery).
@@ -22,17 +22,17 @@ Service Bus **premium** tier supports geo-disaster recovery, at the namespace le
 
 ### Availability zones
 
-The Service Bus **premium** tier supports [availability Zones](../availability-zones/az-overview.md), providing fault-isolated locations within the same Azure region. Service Bus manages three copies of messaging store (1 primary and 2 secondary). Service Bus keeps all three copies in sync for data and management operations. If the primary copy fails, one of the secondary copies is promoted to primary with no perceived downtime. If applications see transient disconnects from Service Bus, the [retry logic](/azure/architecture/best-practices/retry-service-specific#service-bus) in the SDK will automatically reconnect to Service Bus. 
+The Service Bus **premium** tier supports [availability Zones](../availability-zones/az-overview.md), providing fault-isolated locations within the same Azure region. Service Bus manages three copies of messaging store (1 primary and 2 secondary). Service Bus keeps all three copies in sync for data and management operations. If the primary copy fails, one of the secondary copies is promoted to primary with no perceived downtime. If applications see transient disconnects from Service Bus, the [retry logic](/azure/architecture/best-practices/retry-service-specific#service-bus) in the SDK automatically reconnects to Service Bus. 
 
 When you use availability zones, **both metadata and data (messages)** are replicated across data centers in the availability zone. 
 
 > [!NOTE]
 > The availability zones support for the premium tier is only available in [Azure regions](../availability-zones/az-region.md) where availability zones are present.
 
-When you create a premium tier namespace through the portal, the support for availability zones (if available in the selected region) is automatically enabled for the namespace. When creating a premium tier namespace through other mechanisms, such as [ARM / Bicep templates](/azure/templates/microsoft.servicebus/namespaces#sbnamespaceproperties), [CLI](/cli/azure/servicebus/namespace?#az-servicebus-namespace-create-optional-parameters), or [PowerShell](/powershell/module/az.servicebus/new-azservicebusnamespace#-zoneredundant), the property `zoneRedundant` needs to be explicitly set to `true` to enable availability zones (if available in the selected region). There's no additional cost for using this feature and you can't disable or enable this feature after namespace creation.
+When you create a premium tier namespace through the portal, the support for availability zones (if available in the selected region) is automatically enabled for the namespace. When you create a premium tier namespace through other mechanisms, such as [Azure Resource Manager / Bicep templates](/azure/templates/microsoft.servicebus/namespaces#sbnamespaceproperties), [CLI](/cli/azure/servicebus/namespace?#az-servicebus-namespace-create-optional-parameters), or [PowerShell](/powershell/module/az.servicebus/new-azservicebusnamespace#-zoneredundant), the property `zoneRedundant` needs to be explicitly set to `true` to enable availability zones (if available in the selected region). There's no extra cost for using this feature and you can't disable or enable this feature after namespace creation.
 
 ## Protection against outages and disasters - standard tier
-To achieve resilience against datacenter outages when using the standard messaging pricing tier, Service Bus supports two approaches: **active** and **passive** replication. For each approach, if a given queue or topic must remain accessible in the presence of a datacenter outage, you can create it in both namespaces. Both entities can have the same name. For example, a primary queue can be reached under **contosoPrimary.servicebus.windows.net/myQueue**, while its secondary counterpart can be reached under **contosoSecondary.servicebus.windows.net/myQueue**.
+To achieve resilience against datacenter outages with the standard messaging pricing tier, you could use **active** or  **passive** replication. For each approach, if a given queue or topic must remain accessible in the presence of a datacenter outage, you can create it in both namespaces. Both entities can have the same name. For example, a primary queue can be reached under **contosoPrimary.servicebus.windows.net/myQueue**, while its secondary counterpart can be reached under **contosoSecondary.servicebus.windows.net/myQueue**.
 
 >[!NOTE]
 > The **active replication** and **passive replication** setup are general purpose solutions and not specific features of Service Bus. 
@@ -57,9 +57,9 @@ A client receives messages from both queues. Because there's a chance that the r
 
 In general, passive replication is more economical than active replication because in most cases only one operation is performed. Latency, throughput, and monetary cost are identical to the non-replicated scenario.
 
-When using passive replication, in the following scenarios, messages can be lost or received twice:
+When you use passive replication, in the following scenarios, messages can be lost or received twice:
 
-* **Message delay or loss**: Assume that the sender successfully sent a message m1 to the primary queue, and then the queue becomes unavailable before the receiver receives m1. The sender sends a subsequent message m2 to the secondary queue. If the primary queue is temporarily unavailable, the receiver receives m1 after the queue becomes available again. In case of a disaster, the receiver may never receive m1.
+* **Message delay or loss**: Assume that the sender successfully sent a message m1 to the primary queue, and then the queue becomes unavailable before the receiver receives m1. The sender sends a subsequent message m2 to the secondary queue. If the primary queue is temporarily unavailable, the receiver receives m1 after the queue becomes available again. When a disaster happens, the receiver might never receive m1.
 * **Duplicate reception**: Assume that the sender sends a message m to the primary queue. Service Bus successfully processes m but fails to send a response. After the send operation times out, the sender sends an identical copy of m to the secondary queue. If the receiver is able to receive the first copy of m before the primary queue becomes unavailable, the receiver receives both copies of m at approximately the same time. If the receiver isn't able to receive the first copy of m before the primary queue becomes unavailable, the receiver initially receives only the second copy of m, but then receives a second copy of m when the primary queue becomes available.
 
 The [Azure Messaging Replication Tasks with .NET Core][Azure Messaging Replication Tasks with .NET Core] sample demonstrates replication of messages between namespaces.