(DOCSP-44842) copy fix from stakeholders (#99)

* (DOCSP-44842) copy fix from stakeholders

* (DOCSP-44842) addressing copy feedback

* (DOCSP-44842) build error fix

Author: carriecwk

source/scalability.txt

@@ -23,30 +23,32 @@ response to real-time use. {+service+} analyzes the CPU and memory utilization t
 and whether to scale the cluster tier up and down. See :ref:`Cluster tier scaling <cluster-autoscaling>` 
 to learn more about the conditions under which {+service+} scales up or down your cluster nodes. You can 
 also specify a range of maximum and minimum cluster sizes that your cluster can automatically scale 
-to. {+service+} won't scale a cluster if the new tier falls outside of your specified size range or 
-if your memory usage would exceed the capacity of the new tier. Auto-scaling is throttled with a delay 
-to scale a cluster tier up or down. Therefore, it is best suited for a steadily growing or declining 
-application load, not sudden spikes in which the database is being inundated with usage. If your 
-workload experiences frequent spikes or if you are expecting a large increase in traffic because of an 
-event or a launch, MongoDB recommends that you pre-scale programmatically. 
+to in order to guarantee minimum performance or control costs. {+service+} won't scale a cluster if the 
+new tier falls outside of your specified size range or if your memory usage would exceed the capacity of 
+the new tier. Auto-scaling is throttled with a delay to scale a cluster tier up or down to ensure that 
+auto-scaling doesn't cause any application impact. Therefore, it is best suited for a steadily growing or 
+declining application load, not sudden spikes in which the database is being inundated with usage. If your 
+workload experiences frequent spikes or if you are expecting a large increase in traffic because of an event 
+or a launch, MongoDB recommends that you pre-scale programmatically. 
 
 {+service+} deployment templates, as referenced in the :ref:`Recommended Deployment Topologies <arch-center-deployment-topologies>`, 
 provide you with horizontal and vertical scaling options. Specifically, sharding distributes data across 
 numerous machines, which is useful when no single server can handle your workloads. Sharding follows a 
 shared-nothing architecture, a distributed computing architecture where none of the nodes share any 
-resources with each other. See :ref:`Choose a Shard Key <sharding-choose-a-shard-key>` to learn more 
+resources with each other. See :manual:`Choose a Shard Key </core/sharding-choose-a-shard-key>` to learn more 
 about the ideal choice of shard key that allows MongoDB to distribute documents evenly throughout your cluster 
 while faciliating common query patterns. Furthermore, see `Performance Best Practices: Sharding <https://www.mongodb.com/blog/post/performance-best-practices-sharding>`__ 
 to learn about the key sharding strategies, such as ranged sharding, hashed sharding, and zoned sharding.
 
-Upgrading an {+service+} cluster to the next available {+service+} tier is available through the 
-{+service+} control plane GUI or the 
-`Atlas Administration API <https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Clusters/operation/upgradeSharedCluster>`__. 
-Changing an {+service+} tier, either upscaling or downscaling, allows zero downtime, and is performed 
-in a rolling fashion, which involves electing a secondary member as a replacement, promoting this secondary 
-member to become the new primary, then restoring or replacing the failing member 
-to ensure that the cluster is returned to its target configuration as soon as possible. Horizontal 
-scaling occurs post-deployment based on Administrator action, which can be triggered from a programmatic 
+Upgrading an {+service+} {+cluster+} to the next available {+service+} tier is available through the 
+{+service+} control plane GUI, the 
+`Atlas Administration API <https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Clusters/operation/upgradeSharedCluster>`__, 
+or through IaC tools, such as the |ak8so|, the |service-terraform|, or the {+atlas-cli+}. See 
+:ref:`Automation <arch-center-automation>` to learn more. Changing an {+service+} tier, either upscaling or 
+downscaling, allows zero downtime. The tier changes in a rolling fashion, which involves electing a secondary 
+member as a replacement, promoting this secondary member to become the new primary, then restoring or replacing 
+the failing member to ensure that the cluster is returned to its target configuration as soon as possible. 
+Horizontal scaling occurs post-deployment based on Administrator action, which can be triggered from a programmatic 
 script. Some cluster templates require sharded clusters. Starting with MongoDB version 8.0, you may make 
 use of :manual:`embedded config servers </reference/command/transitionFromDedicatedConfigServer>` to reduce 
 costs associated with config servers on small sharded clusters. 
@@ -67,11 +69,10 @@ or event data that only needs to be retained for a limited time. To create a TTL
 an index on a field that holds date values and specify a time-to-live duration in seconds.
 
 {+service+} also provides you with automated tools, such as the :opsmgr:`Performance Advisor </current/tutorial/performance-advisor/>`, 
-to monitor and identify inefficient queries such as adding or removing an index or 
-changing your client's query structure. You can reduce unnecessary compute time and resource 
-consumption by following actionable recommendations to enhance your query performance. Additionally, 
-you can leverage intelligent index recommendations provided by {+service+} to further improve data 
-retrieval efficiency and minimize the resources needed for database operations. 
+to identify and optimize inefficient queries by adding or removing an index or changing your client's query 
+structure. You can reduce unnecessary compute time and resource consumption by following the actionable recommendations 
+to enhance your query performance. Additionally, you can leverage intelligent index recommendations provided by 
+{+service+} to further improve data retrieval efficiency and minimize the resources needed for database operations. 
 
 Recommendations
 ~~~~~~~~~~~~~~~