docs: fix typos in architecture.md

docs/architecture.md

@@ -21,9 +21,9 @@ Incoming samples (writes from Prometheus) are handled by the [distributor](#dist
 
 ## Blocks storage
 
-The blocks storage is based on [Prometheus TSDB](https://prometheus.io/docs/prometheus/latest/storage/): it stores each tenant's time series into their own TSDB which write out their series to a on-disk Block (defaults to 2h block range periods). Each Block is composed by a few files storing the chunks and the block index.
+The blocks storage is based on [Prometheus TSDB](https://prometheus.io/docs/prometheus/latest/storage/): it stores each tenant's time series into their own TSDB which writes out their series to an on-disk Block (defaults to 2h block range periods). Each Block is composed of a few files storing the chunks and the block index.
 
-The TSDB chunk files contain the samples for multiple series. The series inside the Chunks are then indexed by a per-block index, which indexes metric names and labels to time series in the chunk files.
+The TSDB chunk files contain the samples for multiple series. The series inside the chunks are then indexed by a per-block index, which indexes metric names and labels to time series in the chunk files.
 
 The blocks storage doesn't require a dedicated storage backend for the index. The only requirement is an object store for the Block files, which can be:
 
@@ -60,7 +60,7 @@ The **distributor** service is responsible for handling incoming samples from Pr
 
 The validation done by the distributor includes:
 
-- The metric labels name are formally correct
+- The metric label names are formally correct
 - The configured max number of labels per metric is respected
 - The configured max length of a label name and value is respected
 - The timestamp is not older/newer than the configured min/max time range
@@ -80,7 +80,7 @@ The supported KV stores for the HA tracker are:
 * [Consul](https://www.consul.io)
 * [Etcd](https://etcd.io)
 
-Note: Memberlist is not supported. Memberlist-based KV store propagates updates using gossip, which is very slow for HA purposes: result is that different distributors may see different Prometheus server as elected HA replica, which is definitely not desirable.
+Note: Memberlist is not supported. Memberlist-based KV store propagates updates using gossip, which is very slow for HA purposes: the result is that different distributors may see different Prometheus servers as the elected HA replica, which is definitely not desirable.
 
 For more information, please refer to [config for sending HA pairs data to Cortex](guides/ha-pair-handling.md) in the documentation.
 
@@ -97,11 +97,11 @@ The trade-off associated with the latter is that writes are more balanced across
 
 #### The hash ring
 
-A hash ring (stored in a key-value store) is used to achieve consistent hashing for the series sharding and replication across the ingesters. All [ingesters](#ingester) register themselves into the hash ring with a set of tokens they own; each token is a random unsigned 32-bit number. Each incoming series is [hashed](#hashing) in the distributor and then pushed to the ingester owning the tokens range for the series hash number plus N-1 subsequent ingesters in the ring, where N is the replication factor.
+A hash ring (stored in a key-value store) is used to achieve consistent hashing for the series sharding and replication across the ingesters. All [ingesters](#ingester) register themselves into the hash ring with a set of tokens they own; each token is a random unsigned 32-bit number. Each incoming series is [hashed](#hashing) in the distributor and then pushed to the ingester owning the token's range for the series hash number plus N-1 subsequent ingesters in the ring, where N is the replication factor.
 
 To do the hash lookup, distributors find the smallest appropriate token whose value is larger than the [hash of the series](#hashing). When the replication factor is larger than 1, the next subsequent tokens (clockwise in the ring) that belong to different ingesters will also be included in the result.
 
-The effect of this hash set up is that each token that an ingester owns is responsible for a range of hashes. If there are three tokens with values 0, 25, and 50, then a hash of 3 would be given to the ingester that owns the token 25; the ingester owning token 25 is responsible for the hash range of 1-25.
+The effect of this hash setup is that each token that an ingester owns is responsible for a range of hashes. If there are three tokens with values 0, 25, and 50, then a hash of 3 would be given to the ingester that owns token 25; the ingester owning token 25 is responsible for the hash range of 1-25.
 
 The supported KV stores for the hash ring are:
 
@@ -111,7 +111,7 @@ The supported KV stores for the hash ring are:
 
 #### Quorum consistency
 
-Since all distributors share access to the same hash ring, write requests can be sent to any distributor and you can setup a stateless load balancer in front of it.
+Since all distributors share access to the same hash ring, write requests can be sent to any distributor and you can set up a stateless load balancer in front of it.
 
 To ensure consistent query results, Cortex uses [Dynamo-style](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) quorum consistency on reads and writes. This means that the distributor will wait for a positive response of at least one half plus one of the ingesters to send the sample to before successfully responding to the Prometheus write request.
 
@@ -125,35 +125,35 @@ The **ingester** service is responsible for writing incoming series to a [long-t
 
 Incoming series are not immediately written to the storage but kept in memory and periodically flushed to the storage (by default, 2 hours). For this reason, the [queriers](#querier) may need to fetch samples both from ingesters and long-term storage while executing a query on the read path.
 
-Ingesters contain a **lifecycler** which manages the lifecycle of an ingester and stores the **ingester state** in the [hash ring](#the-hash-ring). Each ingester could be in one of the following states:
+Ingesters contain a **lifecycler** which manages the lifecycle of an ingester and stores the **ingester state** in the [hash ring](#the-hash-ring). Each ingester can be in one of the following states:
 
 - **`PENDING`**<br />
-  The ingester has just started. While in this state, the ingester doesn't receive neither write and read requests.
+  The ingester has just started. While in this state, the ingester doesn't receive either write or read requests.
 - **`JOINING`**<br />
-  The ingester is starting up and joining the ring. While in this state the ingester doesn't receive neither write and read requests. The ingester will join the ring using tokens loaded from disk (if `-ingester.tokens-file-path` is configured) or generate a set of new random ones. Finally, the ingester optionally observes the ring for tokens conflicts and then, once any conflict is resolved, will move to `ACTIVE` state.
+  The ingester is starting up and joining the ring. While in this state the ingester doesn't receive either write or read requests. The ingester will join the ring using tokens loaded from disk (if `-ingester.tokens-file-path` is configured) or generate a set of new random ones. Finally, the ingester optionally observes the ring for token conflicts and then, once any conflict is resolved, will move to `ACTIVE` state.
 - **`ACTIVE`**<br />
   The ingester is up and running. While in this state the ingester can receive both write and read requests.
 - **`LEAVING`**<br />
-  The ingester is shutting down and leaving the ring. While in this state the ingester doesn't receive write requests, while it could receive read requests.
+  The ingester is shutting down and leaving the ring. While in this state the ingester doesn't receive write requests, while it can still receive read requests.
 - **`UNHEALTHY`**<br />
   The ingester has failed to heartbeat to the ring's KV Store. While in this state, distributors skip the ingester while building the replication set for incoming series and the ingester does not receive write or read requests.
 
 Ingesters are **semi-stateful**.
 
-#### Ingesters failure and data loss
+#### Ingester failure and data loss
 
 If an ingester process crashes or exits abruptly, all the in-memory series that have not yet been flushed to the long-term storage will be lost. There are two main ways to mitigate this failure mode:
 
 1. Replication
 2. Write-ahead log (WAL)
 
-The **replication** is used to hold multiple (typically 3) replicas of each time series in the ingesters. If the Cortex cluster loses an ingester, the in-memory series held by the lost ingester are also replicated to at least another ingester. In the event of a single ingester failure, no time series samples will be lost. However, in the event of multiple ingester failures, time series may be potentially lost if the failures affect all the ingesters holding the replicas of a specific time series.
+The **replication** is used to hold multiple (typically 3) replicas of each time series in the ingesters. If the Cortex cluster loses an ingester, the in-memory series held by the lost ingester are also replicated to at least one other ingester. In the event of a single ingester failure, no time series samples will be lost. However, in the event of multiple ingester failures, time series may be potentially lost if the failures affect all the ingesters holding the replicas of a specific time series.
 
 The **write-ahead log** (WAL) is used to write to a persistent disk all incoming series samples until they're flushed to the long-term storage. In the event of an ingester failure, a subsequent process restart will replay the WAL and recover the in-memory series samples.
 
-Contrary to the sole replication and given the persistent disk data is not lost, in the event of multiple ingesters failure each ingester will recover the in-memory series samples from WAL upon subsequent restart. The replication is still recommended in order to ensure no temporary failures on the read path in the event of a single ingester failure.
+Contrary to the sole replication and given that the persistent disk data is not lost, in the event of multiple ingester failures each ingester will recover the in-memory series samples from WAL upon subsequent restart. The replication is still recommended in order to ensure no temporary failures on the read path in the event of a single ingester failure.
 
-#### Ingesters write de-amplification
+#### Ingester write de-amplification
 
 Ingesters store recently received samples in-memory in order to perform write de-amplification. If the ingesters would immediately write received samples to the long-term storage, the system would be very difficult to scale due to the very high pressure on the storage. For this reason, the ingesters batch and compress samples in-memory and periodically flush them out to the storage.
 
@@ -169,10 +169,10 @@ Queriers are **stateless** and can be scaled up and down as needed.
 
 ### Compactor
 
-The **compactor** is a service which is responsible to:
+The **compactor** is a service which is responsible for:
 
-- Compact multiple blocks of a given tenant into a single optimized larger block. This helps to reduce storage costs (deduplication, index size reduction), and increase query speed (querying fewer blocks is faster).
-- Keep the per-tenant bucket index updated. The [bucket index](./blocks-storage/bucket-index.md) is used by [queriers](./blocks-storage/querier.md), [store-gateways](#store-gateway) and rulers to discover new blocks in the storage.
+- Compacting multiple blocks of a given tenant into a single optimized larger block. This helps to reduce storage costs (deduplication, index size reduction), and increase query speed (querying fewer blocks is faster).
+- Keeping the per-tenant bucket index updated. The [bucket index](./blocks-storage/bucket-index.md) is used by [queriers](./blocks-storage/querier.md), [store-gateways](#store-gateway) and rulers to discover new blocks in the storage.
 
 For more information, see the [compactor documentation](./blocks-storage/compactor.md).
 
@@ -190,7 +190,7 @@ The store gateway is **semi-stateful**.
 
 ### Query frontend
 
-The **query frontend** is an **optional service** providing the querier's API endpoints and can be used to accelerate the read path. When the query frontend is in place, incoming query requests should be directed to the query frontend instead of the queriers. The querier service will be still required within the cluster, in order to execute the actual queries.
+The **query frontend** is an **optional service** providing the querier's API endpoints and can be used to accelerate the read path. When the query frontend is in place, incoming query requests should be directed to the query frontend instead of the queriers. The querier service will still be required within the cluster, in order to execute the actual queries.
 
 The query frontend internally performs some query adjustments and holds queries in an internal queue. In this setup, queriers act as workers which pull jobs from the queue, execute them, and return them to the query-frontend for aggregation. Queriers need to be configured with the query frontend address (via the `-querier.frontend-address` CLI flag) in order to allow them to connect to the query frontends.
 
@@ -199,15 +199,15 @@ Query frontends are **stateless**. However, due to how the internal queue works,
 Flow of the query in the system when using query-frontend:
 
 1) Query is received by query frontend, which can optionally split it or serve from the cache.
-2) Query frontend stores the query into in-memory queue, where it waits for some querier to pick it up.
+2) Query frontend stores the query into an in-memory queue, where it waits for some querier to pick it up.
 3) Querier picks up the query, and executes it.
 4) Querier sends result back to query-frontend, which then forwards it to the client.
 
-Query frontend can also be used with any Prometheus-API compatible service. In this mode Cortex can be used as an query accelerator with it's caching and splitting features on other prometheus query engines like Thanos Querier or your own Prometheus server. Query frontend needs to be configured with downstream url address(via the `-frontend.downstream-url` CLI flag), which is the endpoint of the prometheus server intended to be connected with Cortex.
+Query frontend can also be used with any Prometheus-API compatible service. In this mode Cortex can be used as a query accelerator with its caching and splitting features on other prometheus query engines like Thanos Querier or your own Prometheus server. Query frontend needs to be configured with downstream url address (via the `-frontend.downstream-url` CLI flag), which is the endpoint of the prometheus server intended to be connected with Cortex.
 
 #### Queueing
 
-The query frontend queuing mechanism is used to:
+The query frontend queueing mechanism is used to:
 
 * Ensure that large queries, that could cause an out-of-memory (OOM) error in the querier, will be retried on failure. This allows administrators to under-provision memory for queries, or optimistically run more small queries in parallel, which helps to reduce the total cost of ownership (TCO).
 * Prevent multiple large requests from being convoyed on a single querier by distributing them across all queriers using a first-in/first-out queue (FIFO).
@@ -223,7 +223,7 @@ The query frontend supports caching query results and reuses them on subsequent
 
 ### Query Scheduler
 
-Query Scheduler is an **optional** service that moves the internal queue from query frontend into separate component.
+Query Scheduler is an **optional** service that moves the internal queue from query frontend into a separate component.
 This enables independent scaling of query frontends and number of queues (query scheduler).
 
 In order to use query scheduler, both query frontend and queriers must be configured with query scheduler address
@@ -232,10 +232,10 @@ In order to use query scheduler, both query frontend and queriers must be config
 Flow of the query in the system changes when using query scheduler:
 
 1) Query is received by query frontend, which can optionally split it or serve from the cache.
-2) Query frontend forwards the query to random query scheduler process.
-3) Query scheduler stores the query into in-memory queue, where it waits for some querier to pick it up.
-3) Querier picks up the query, and executes it.
-4) Querier sends result back to query-frontend, which then forwards it to the client.
+2) Query frontend forwards the query to a random query scheduler process.
+3) Query scheduler stores the query into an in-memory queue, where it waits for some querier to pick it up.
+4) Querier picks up the query, and executes it.
+5) Querier sends result back to query-frontend, which then forwards it to the client.
 
 Query schedulers are **stateless**. It is recommended to run two replicas to make sure queries can still be serviced while one replica is restarting.
 
@@ -263,7 +263,7 @@ If all of the alertmanager nodes failed simultaneously there would be a loss of
 ### Configs API
 
 The **configs API** is an **optional service** managing the configuration of Rulers and Alertmanagers.
-It provides APIs to get/set/update the ruler and alertmanager configurations and store them into backend.
-Current supported backend are PostgreSQL and in-memory.
+It provides APIs to get/set/update the ruler and alertmanager configurations and store them in the backend.
+Current supported backends are PostgreSQL and in-memory.
 
 Configs API is **stateless**.