Update system design introduction and load balancing

README.md

@@ -63,10 +63,10 @@
 
 ## System design
 
-> For a complete System Design study, you should also be familiar with Databases related topics such as CAP Theorem.
+> For a complete System Design study, you should also be familiar with Databases related topics such as CAP Theorem. This section assumes prior knowledge about such topics, but you can also read about those in this very same repo.
 
-- [Introduction](system-design)
-- [Where to start](system-design/how-to)
+- [Introduction](system-design/README.md)
+- [How to approach a design](system-design/how-to)
 - [Performance Measures](system-design/performance-measures)
   - Response time
   - Responsiveness
@@ -76,11 +76,11 @@
   - Load sensitivity
   - Capacity
   - Scalability
+- [Load Balancing](system-design/load-balancing)
 - [Sustainability](system-design/sustainability)
 - [Scalability](system-design/scalability)
   - [Vertical Scaling (scale up/down)](system-design/scalability/vertical-scaling)
   - [Horizontal Scaling (scale out/in)](system-design/scalability/horizontal-scaling)
-- [Load Balancing](system-design/load-balancing)
 - [Caching](system-design/caching)
 - [RAID](system-design/raid)
 - [Consistency](system-design/consistency)

system-design/README.md

@@ -4,11 +4,15 @@
 
 System design is a broad topic. There is a vast amount of resources scattered throughout the web on system design principles.
 
-> Everything is a trade off
+> Everything is a trade-off.
 
-## Study Guide
+## The getting started architecture
 
-![](2021-06-28-09-42-20.png)
+You should be familiar with the classic "getting started" architecture. This is what most applications get started with, a simple web server that communicates with a single database and is exposed via a public DNS.
+
+![img.png](img.png)
+
+This is more than enough to get an application working as fast as possible, but you'll start finding limitations soon.
 
 ## Examples
 

system-design/availability/README.md

@@ -1,16 +1,23 @@
 # Availability
 
-Definition from [CAP Theorem](../cap): Every request receives a response, without guarantee that it contains the most recent version of the information.
+<!-- TOC -->
+* [Availability](#availability)
+  * [Definition](#definition)
+  * [Availability patterns](#availability-patterns)
+    * [Fail-over](#fail-over)
+      * [Active-Passive / Master-Slave](#active-passive--master-slave)
+      * [Active-Active / Master-Master](#active-active--master-master)
+    * [Replication](#replication)
+  * [In Parallel vs In Sequence](#in-parallel-vs-in-sequence)
+<!-- TOC -->
 
-## In Parallel vs In Sequence
-
-If a servir consists of multiple components prone to failure, the service's overall availability depends on whether the components are in sequence or in parallel
+## Definition
 
-* In Sequence: `Availability (Total) = Availability (c1) * Availability (c2) * ...`
+Availability is defined on the [CAP Theorem](../cap) as:
 
-* In Parallel: `Availability (Total) = 1 - (1 - Availability (c1)) * (1 - Availability (c2)) * ...`
+Every request receives a response, without guarantee that it contains the most recent version of the information.
 
-## Availability Patterns
+## Availability patterns
 
 There are two complementary patterns to support *high availability*: **fail-over** and **replication**.
 
@@ -36,3 +43,11 @@ if the servers are public-facing, the DNS would need to know about the public IP
 ### Replication
 
 See [Replication in Databases](../../databases/replication).
+
+## In Parallel vs In Sequence
+
+If a service consists of multiple components prone to failure, the service's overall availability depends on whether the components are in sequence or in parallel
+
+* In Sequence: `Availability (Total) = Availability (c1) * Availability (c2) * ...`
+
+* In Parallel: `Availability (Total) = 1 - (1 - Availability (c1)) * (1 - Availability (c2)) * ...`

system-design/choosing-database/README.md

@@ -7,8 +7,6 @@
 
 ## Overview
 
-![](2021-08-28-20-31-52.png)
-
 The reason that we have many database options available today is due to the [CAP theorem](../databases/CAP).
 
 > CAP Theorem: At any given time, you can only guarantee two of the following: consistency, availability, and partition tolerance. 

system-design/how-to/README.md

@@ -1,5 +1,13 @@
 # How To Approach
 
+<!-- TOC -->
+* [How To Approach](#how-to-approach)
+  * [1. Outline use cases, constraints and assumptions](#1-outline-use-cases-constraints-and-assumptions)
+  * [2. Create a high level design](#2-create-a-high-level-design)
+  * [3. Design core components](#3-design-core-components)
+  * [4. Scale the design](#4-scale-the-design)
+<!-- TOC -->
+
 > The system design interview is an open-ended conversation. You are expected to lead it.
 
 You can use the following steps to guide the discussion. As an exercise, you can work through [system design interview questions with solutions](https://github.com/donnemartin/system-design-primer#system-design-interview-questions-with-solutions) using these steps.

system-design/load-balancing/README.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-![](2021-08-28-20-31-28.png)
+![img_1.png](img_1.png)
 
 * *Load Balancing* refers to the process of **distributing a set of tasks over a set of resources** (computing units), with aim of making their overall processing more efficient.
 
@@ -18,4 +18,4 @@ Two main approaches exist:
 
 * **Static Algorithms**: Don't take into account the state of the different machines.
 
-* **Dynamic algorithms**: Usually more general and more efficient, but requiere exchanges of information between the different computing units, at the risk of a loss of efficiency.
+* **Dynamic algorithms**: Usually more general and more efficient, but require exchanges of information between the different computing units, at the risk of a loss of efficiency.

system-design/scalability/README.md

@@ -21,7 +21,7 @@ A service is scalable if it results in **increased performance in a manner propo
 
 ## Domains
 
-* A scalable **database managment system** or **online transaction processing system** is one that can be upgraded to process more transactions by adding new processors, devices and storage, and which can be upgraded easily and transparently without shutting it down.
+* A scalable **database management system** or **online transaction processing system** is one that can be upgraded to process more transactions by adding new processors, devices and storage, and which can be upgraded easily and transparently without shutting it down.
 
 * A **routing protocol** is considered scalable with respect to network size, if the size of the necessary *routing table* on each node grows as *O(log n)*, where *n* is the number of nodes in the network.
   * Some P2P systems like BitTorrent scale well because the demand on each peer is independent of the number of peers. Nothing is centralized, so the system can expand indefinitely without any resources other than the peer themselves.