Add more diagrams

Author: NataliaIvakina

modules/ROOT/images/2dc-balanced-membership.svg

@@ -24,6 +24,8 @@ If primaries are far apart, network latency adds to commit time.
 [[secondaries-for-read-resilience]]
 === Use database secondaries for read resilience
 
+image::secondaries-for-read-resilience.svg[width="400", title="Cluster design with database secondaries for better read performance", role=popup]
+
 You can locate all the database primaries in one data center (DC) and database secondaries in another DC for better read performance.
 This provides fast writes, because they will be performed within the DC.
 
@@ -54,7 +56,9 @@ For detailed scenarios, see the xref:clustering/multi-region-deployment/disaster
 
 
 [[geo-distributed-dc]]
-=== Use geo-distributed data centers (3DC)
+=== Use geo-distributed data centers
+
+image::geo-distributed-primaries.svg[width="400", title="Cluster design with primaries distributed across three data centers", role=popup]
 
 You can place each primary server in a different data center using a minimum of three data centers.
 
@@ -82,7 +86,7 @@ For detailed scenarios, see the xref:clustering/multi-region-deployment/disaster
 
 
 [[geo-distribution-system-database]]
-=== Use full geo-distribution for the `system` database only (3DC)
+=== Use full geo-distribution for the `system` database only
 
 image::geo-distribution-system-db.svg[width="400", title="Primaries for the `system` database distributed across three data centers", role=popup]
 
@@ -124,6 +128,8 @@ You need to accept a smaller topology that fits in the remaining data center.
 [[two-dc-unbalanced-membership]]
 === Two data centers with unbalanced membership
 
+image::2dc-unbalanced-membership.svg[width="400", title="Unbalanced data center primary distribution", role=popup]
+
 Suppose you decide to set up just two data centers, placing two primaries in data center 1 (DC1) and one primary in the data center 2 (DC2).
 
 If the writer primary is located in DC1, then writes can be fast because a local quorum can be reached.
@@ -136,14 +142,16 @@ In that case a failure of a member in DC1 means the database is write-unavailabl
 
 If leadership shifts to DC2, this makes all writes slow.
 
-Finally, there is no guarantee against data lost if DC1 goes down.
+Finally, there is no guarantee against data loss if DC1 goes down.
 Beacuse the primary member in DC2 may not be up to date with writes, even in append.
 
 
 
 [[two-dc-balanced-membership]]
 === Two data centers with balanced membership
 
+image::2dc-balanced-membership.svg[width="400", title="Symmetric primaries across two data centers", role=popup]
+
 The worst scenario is to operate with just two data centers and place two or three primaries in each of them.
 
 This means the failure of either data center leads to loss of quorum and, therefore, to loss of the cluster write-availability.