From 8855d3df4301770c2b9354b1c6b9fc3c06947ce6 Mon Sep 17 00:00:00 2001
From: Trystan Schneider <163326670+tschneider-aneo@users.noreply.github.com>
Date: Wed, 2 Oct 2024 10:44:02 +0200
Subject: [PATCH] Update AEP/aep-00004.md

Co-authored-by: ngruelaneo <100275739+ngruelaneo@users.noreply.github.com>
---
 AEP/aep-00004.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/AEP/aep-00004.md b/AEP/aep-00004.md
index 120c6f6..dfd48c7 100644
--- a/AEP/aep-00004.md
+++ b/AEP/aep-00004.md
@@ -62,7 +62,7 @@ In a sharded cluster, the mongos instances are similar to the role of the databa
 
 Note that the config server is also deployed as a replica set. It is not clear in the schema above because we didn't want to overload it with too much information, as we are focusing on sharding user-intended database.
 
-Finally, also note that multiple mongos routers can be deployed in the cluster too but no need for replica set as they are stateless.
+It is important to notice that multiple mongos routers can also be deployed in the cluster but there are no need for replica set as they are stateless.
 
 # Rationale
 Sharding the database would alleviate the tension on all the nodes. For the primary nodes, the write operations would be distributed among other shards' primary node, and for the secondary nodes there can be some situations where only the right shard is queried (it will be explicited below in this AEP) and as mentionned above, the read operations are faster on a sharded cluster since the data is distributed among multiple instances.