Update graphic

v19.1/cluster-topology-patterns.md

@@ -23,9 +23,9 @@ This page does not factor in hardware differences.
 
 ## Single datacenter clusters
 
-### Basic pattern for a local deployment
+### Basic pattern for a single datacenter cluster
 
-This first example is of a local deployment, which is a single datacenter cluster. This pattern is common starting point for smaller organizations who may not have the resources (or need) to worry about a datacenter failure, but still want to take advantage of CockroachDB's [high availability](high-availability.html). The cluster is self-hosted with each node on a different machine within the same datacenter. The network latency among the nodes is expected to be the same, around 1ms.
+This first example is of a single datacenter cluster, i.e., a local deployment. This pattern is common starting point for smaller organizations who may not have the resources (or need) to worry about a datacenter failure, but still want to take advantage of CockroachDB's [high availability](high-availability.html). The cluster is self-hosted with each node on a different machine within the same datacenter. The network latency among the nodes is expected to be the same, around 1ms.
 
 <img src="{{ 'images/v19.1/topology-patterns/basic-local-deployment.png' | relative_url }}" alt="Local deployment" style="border:1px solid #eee;max-width:100%" />
 
@@ -102,7 +102,7 @@ For this example:
 - A software-based load balancer directs traffic to any of the regions' nodes at random
 - Every region has 3 datacenters
 - All CockroachDB nodes communicate with each other
-- Similar to the [local](#single-local-datacenter-clusters) topology, more regions can be added dynamically
+- Similar to the [local](#single-datacenter-clusters) topology, more regions can be added dynamically
 - A homogenous configuration among the regions for simplified operations is recommended
 - For sophisticated workloads, each region can have different node count and node specification. This heterogeneous configuration could better handle regional specific concurrency and load characteristics.
 
@@ -124,12 +124,11 @@ If all of the nodes for a preferred locality are down, then the app will try dat
 
 ### More performant multi-region cluster
 
-users across the country and want to keep data close to them so reads/ writes are fast
-eliminate cross country roundtrips
+While the [basic pattern for a multi-region cluster](#basic-pattern-for-a-multi-region-cluster) can help protect against regional failures, there will be high latency due to cross-country roundtrips. This is not ideal for organizations who have users spread out across the country. For any multi-region cluster, [partitioning](partitioning.html) should be used to keep data close to the users who access it.
 
 <img src="{{ 'images/v19.1/topology-patterns/multi-region-partition.png' | relative_url }}" alt="Multi-region partition" style="border:1px solid #eee;max-width:100%" />
 
-This setup uses modern [multi-tier architecture](https://en.wikipedia.org/wiki/Multitier_architecture), which is simplified to global server load balancer (`GSLB`), `App`, and `Load Balancer` layers in the below diagram:
+This setup uses a modern [multi-tier architecture](https://en.wikipedia.org/wiki/Multitier_architecture), which is simplified to global server load balancer (`GSLB`), `App`, and `Load Balancer` layers in the below diagram:
 
 <img src="{{ 'images/v19.1/topology-patterns/multi-tier-architecture.png' | relative_url }}" alt="Multi-tier architecture" style="border:1px solid #eee;max-width:100%" />
 
@@ -196,7 +195,7 @@ Some applications have high-performance requirements. In the diagram below, `NJ`
 
 In this pattern:
 
-- `NJ` and `NY` have the performance characteristics of the [local topology](#single-local-datacenter-clusters), but the benefit of Zero RPO (recovery point objective) and near Zero RTO (recovery time objective) disaster recovery SLA. `CA` and `NV` are set up similarly.
+- `NJ` and `NY` have the performance characteristics of the [local topology](#single-datacenter-clusters), but the benefit of Zero RPO (recovery point objective) and near Zero RTO (recovery time objective) disaster recovery SLA. `CA` and `NV` are set up similarly.
 - The `Central` region serves as the quorum. `NJ` and `NY` are close, `CA` and `NV` are close to each other, and `Central` is halfway between both pairs to achieve quorum fast. To do this, the cluster needs to be [partitioned](partitioning.html).
 - downsides: you'd have to use zone configs for this (right?) and east - west partition their data. this might require application changes.