From d6f2f2dbc876d9e3e8ab14cd635e642664555636 Mon Sep 17 00:00:00 2001 From: Sanket Patel Date: Tue, 29 Dec 2020 22:08:19 +0530 Subject: [PATCH] fix typo #78 --- courses/systems_design/scalability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/courses/systems_design/scalability.md b/courses/systems_design/scalability.md index 9b0d5c6..a69ff2c 100644 --- a/courses/systems_design/scalability.md +++ b/courses/systems_design/scalability.md @@ -21,7 +21,7 @@ Let's see how our monolithic application improves with this principle ![Horizontal Scaling](images/horizontal-scaling.jpg) -Here DB is scaled separately from the application. This is to let you know each component’s scaling capabilities can be different. Usually, web applications can be scaled by adding resources unless there is no state stored inside the application. But DBs can be scaled only for Reads by adding more followers but Writes have to go to only one leader to make sure data is consistent. There are some DBs that support multi-leader writes but we are keeping them out of scope at this point. +Here DB is scaled separately from the application. This is to let you know each component’s scaling capabilities can be different. Usually, web applications can be scaled by adding resources unless there is state stored inside the application. But DBs can be scaled only for Reads by adding more followers but Writes have to go to only one leader to make sure data is consistent. There are some DBs that support multi-leader writes but we are keeping them out of scope at this point. Apps should be able to differentiate between Reads and Writes to choose appropriate DB servers. Load balancers can split traffic between identical servers transparently.