more edits for better readability

Author: NataliaIvakina

modules/ROOT/pages/clustering/multi-region-deployment/geo-redundant-deployment.adoc

@@ -2,7 +2,7 @@
 [role=enterprise-edition]
 
 
-= Design a resilient multi-data center cluster
+= Designing a resilient multi-data center cluster
 
 [[multi-region-deployment-overview]]
 == Overview
@@ -26,8 +26,8 @@ If primaries are far apart, network latency adds to commit time.
 
 image::secondaries-for-read-resilience.svg[width="400", title="Cluster design with database secondaries for better read performance", role=popup]
 
-For better read performance, you can locate all database primaries in one data center (DC) and database secondaries in another DC.
-This also provides fast writes, because they will be performed within the DC.
+For better read performance, you can locate all database primaries in one data center (DC) and the secondaries in another DC.
+This setup also provides fast writes, because they will be performed within the single DC.
 
 However, if the DC with primaries goes down, your cluster loses write availability.
 Though read availability may remain via the secondaries.
@@ -36,7 +36,7 @@ Though read availability may remain via the secondaries.
 
 You can restore the cluster write availability without the failed DC:
 
-* If you have enough secondary members of the database in another data center, you can switch their mode to primary and not have to store a copy or wait a long time for primary copies to restore.
+* If you have enough secondary members of the database in another DC, you can switch their mode to primary and not have to store a copy or wait a long time for primary copies to restore.
 * You can use secondaries to re-seed databases if needed.
 See xref:database-administration/standard-databases/recreate-database.adoc[the `dbms.recreateDatabase()` procedure] for more details.
 
@@ -60,9 +60,9 @@ For detailed scenarios, see the xref:clustering/multi-region-deployment/disaster
 
 image::geo-distributed-primaries.svg[width="400", title="Cluster design with database primaries distributed across three data centers", role=popup]
 
-You can place each primary copy in a different data center (DC) using a minimum of three data centers.
+You can place each primary copy in a different data center (DC), using at least three data centers.
 
-Therefore, if one DC fails, only one primary member is lost and the cluster can continue without data loss.
+Therefore, if one DC fails, only a single primary member is lost, and the cluster can continue operating without data loss.
 
 However, you always pay cross-data center latency times for every write operation.
 
@@ -91,20 +91,20 @@ For detailed scenarios, see the xref:clustering/multi-region-deployment/disaster
 
 image::geo-distribution-system-db.svg[width="400", title="Primaries for the `system` database distributed across three data centers", role=popup]
 
-You can place all primaries for user databases in one data center (DC), with secondaries in another.
+You can place all primaries for user databases in one data center (DC) and all secondaries in another.
 
 In a third DC, deploy a server that only hosts a primary member of the `system` database (in addition to those in the first two data centers).
 
 * This server can be a small machine, since the `system` database has minimal resource requirements.
 
 * To prevent user databases from being allocated to it, set the `allowedDatabases` constraint to some name that will never be used.
 
-Your writes will be fast, because they are within the DC.
+Your writes will be fast, because they occur within the single DC.
 
 If a DC goes down, you retain write availability for the `system` database, which makes restoring write availability to the user databases easier.
 
 However, if the DC with primaries goes down, the user databases will become write-unavailable.
-Though read availability may remain via the secondaries.
+Though read availability may still be maintained via the secondaries.
 
 ==== Recovering from the loss of a data center