From eb318fad5c728337d3b522482e2ef6c222b396f0 Mon Sep 17 00:00:00 2001 From: Samar Dhwoj Acharya Date: Sat, 7 Oct 2017 11:06:37 -0500 Subject: [PATCH] Fix typo: considering to consider in scaling AWS solution (#109) --- solutions/system_design/scaling_aws/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/solutions/system_design/scaling_aws/README.md b/solutions/system_design/scaling_aws/README.md index 9134983..ddd43dc 100644 --- a/solutions/system_design/scaling_aws/README.md +++ b/solutions/system_design/scaling_aws/README.md @@ -309,7 +309,7 @@ As the service continues to grow towards the figures outlined in the constraints We'll continue to address scaling issues due to the problem's constraints: -* If our **MySQL Database** starts to grow too large, we might considering only storing a limited time period of data in the database, while storing the rest in a data warehouse such as Redshift +* If our **MySQL Database** starts to grow too large, we might consider only storing a limited time period of data in the database, while storing the rest in a data warehouse such as Redshift * A data warehouse such as Redshift can comfortably handle the constraint of 1 TB of new content per month * With 40,000 average read requests per second, read traffic for popular content can be addressed by scaling the **Memory Cache**, which is also useful for handling the unevenly distributed traffic and traffic spikes * The **SQL Read Replicas** might have trouble handling the cache misses, we'll probably need to employ additional SQL scaling patterns