Add content to system design roadmap

src/roadmaps/system-design/content/100-introduction/101-how-to-approach-system-design.md

@@ -1,4 +1,4 @@
-# How to approach System Design?
+# How To: System Design?
 
 There are several steps that can be taken when approaching a system design:
 
@@ -10,4 +10,9 @@ There are several steps that can be taken when approaching a system design:
 - **Document the design:** Create detailed documentation of your design for future reference and maintenance.
 - **Continuously monitor and improve the system:** The system design is not a one-time process, it needs to be continuously monitored and improved to meet the changing requirements.
 
-Note that this is a general approach and the steps may vary depending on the specific system and requirements.
+Note that this is a general approach to System Design. For interview specific answers, see the following resources:
+
+* [How to approach System Design?](https://github.com/donnemartin/system-design-primer#how-to-approach-a-system-design-interview-question)
+* [What are system design questions?](https://www.hiredintech.com/system-design)
+* [Intro to Architecture and Systems Design Interviews](https://www.youtube.com/watch?v=ZgdS0EUmn70)
+* [My System Design Template](https://leetcode.com/discuss/career/229177/My-System-Design-Template)

src/roadmaps/system-design/content/100-introduction/102-who-is-this-guide-for.md

@@ -1 +1,3 @@
-# Who is this guide for
+# Who is this guide for?
+
+This guide is intended for a wide range of individuals including software engineers, system administrators, and IT professionals who are interested in understanding the principles and best practices of designing scalable systems. It is also useful for those who are preparing for system design interviews as it provides a comprehensive understanding of the key concepts and considerations involved in the design process. The guide covers a variety of System Design topics with detailed explanations and external links for learning more about each topic.

src/roadmaps/system-design/content/101-performance-vs-scalability.md

@@ -1,11 +1,11 @@
 # Performance vs Scalability
 
-A service is scalable if it results in increased performance in a manner proportional to resources added. Generally, increasing performance means serving more units of work, but it can also be to handle larger units of work, such as when datasets grow.1
+A service is **scalable** if it results in increased **performance** in a manner proportional to resources added. Generally, increasing performance means serving more units of work, but it can also be to handle larger units of work, such as when datasets grow. 
 
 Another way to look at performance vs scalability:
 
-- If you have a performance problem, your system is slow for a single user.
-- If you have a scalability problem, your system is fast for a single user but slow under heavy load.
+- If you have a **performance** problem, your system is slow for a single user.
+- If you have a **scalability** problem, your system is fast for a single user but slow under heavy load.
 
 To learn more, visit the following links:
 

src/roadmaps/system-design/content/102-latency-vs-throughput.md

@@ -1,7 +1,10 @@
 # Latency vs Throughput
 
-Latency is the time to perform some action or to produce some result. Throughput is the number of such actions or results per unit of time Generally, you should aim for maximal throughput with acceptable latency.
+Latency and throughput are two important measures of a system's performance. **Latency** refers to the amount of time it takes for a system to respond to a request. **Throughput** refers to the number of requests that a system can handle at the same time.
+
+Generally, you should aim for maximal throughput with acceptable latency.
 
 Learn more from the following links:
 
+- [System Design: Latency vs Throughput](https://cs.fyi/guide/latency-vs-throughput/)
 - [Understanding Latency versus Throughput](https://community.cadence.com/cadence_blogs_8/b/fv/posts/understanding-latency-vs-throughput)

src/roadmaps/system-design/content/103-availability-vs-consistency/100-cap-theorem.md

@@ -1,6 +1,6 @@
 # CAP Theorem
 
-In a distributed computer system, you can only support two of the following guarantees:
+According to CAP theorem, in a distributed system, you can only support two of the following guarantees:
 
 - **Consistency** - Every read receives the most recent write or an error
 - **Availability** - Every request receives a response, without guarantee that it contains the most recent version of the information

src/roadmaps/system-design/content/103-availability-vs-consistency/index.md

@@ -1,13 +1,14 @@
 # Availability vs Consistency
 
-A service is scalable if it results in increased performance in a manner proportional to resources added. Generally, increasing performance means serving more units of work, but it can also be to handle larger units of work, such as when datasets grow.
+Availability refers to the ability of a system to provide its services to clients even in the presence of failures. This is often measured in terms of the percentage of time that the system is up and running, also known as its uptime.
 
-Another way to look at performance vs scalability:
+Consistency, on the other hand, refers to the property that all clients see the same data at the same time. This is important for maintaining the integrity of the data stored in the system.
 
-- If you have a performance problem, your system is slow for a single user.
-- If you have a scalability problem, your system is fast for a single user but slow under heavy load.
+In distributed systems, it is often a trade-off between availability and consistency. Systems that prioritize high availability may sacrifice consistency, while systems that prioritize consistency may sacrifice availability. Different distributed systems use different approaches to balance the trade-off between availability and consistency, such as using replication or consensus algorithms.
 
 Have a look at the following resources to learn more:
 
-- [A Word on Scalability](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
-- [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
+- [CAP Theorem](https://www.youtube.com/watch?v=_RbsFXWRZ10&t=1s)
+- [CAP Theorem Revisited](https://robertgreiner.com/cap-theorem-revisited/)
+- [A plain english introduction to CAP Theorem](http://ksat.me/a-plain-english-introduction-to-cap-theorem)
+- [CAP FAQ](https://github.com/henryr/cap-faq)

src/roadmaps/system-design/content/104-consistency-patterns/100-weak-consistency.md

@@ -3,6 +3,4 @@
 After a write, reads may or may not see it. A best effort approach is taken. This approach is seen in systems such as memcached. Weak consistency works well in real time use cases such as VoIP, video chat, and realtime multiplayer games. For example, if you are on a phone call and lose reception for a few seconds, when you regain connection you do not hear what was spoken during connection loss.
 
 To learn more, visit the following links:
-- [Introduction to Weak Consistency](https://github.com/donnemartin/system-design-primer)
-- [Guide to Weak Consistency](https://iq.opengenus.org/consistency-patterns-in-system-design/)
-
+- [Consistency Patterns in Distributed Systems](https://cs.fyi/guide/consistency-patterns-week-strong-eventual/)

src/roadmaps/system-design/content/104-consistency-patterns/101-eventual-consistency.md

@@ -5,5 +5,4 @@ After a write, reads will eventually see it (typically within milliseconds).Data
 
 To learn more, visit the following links:
 
-- [Eventual Consistency Patterns](https://github.com/donnemartin/system-design-primer)
-- [System Design Concepts – Eventual Consistency](https://www.acodersjourney.com/eventual-consistency/)
+- [Consistency Patterns in Distributed Systems](https://cs.fyi/guide/consistency-patterns-week-strong-eventual/)

src/roadmaps/system-design/content/104-consistency-patterns/102-strong-consistency.md

@@ -4,5 +4,4 @@ After a write, reads will see it. Data is replicated synchronously. This approac
 
 To learn more, visit the following links:
 
-- [Strong Consistency Patterns](https://github.com/donnemartin/system-design-primer)
-- [Get started with Strong Consistency](https://www.geeksforgeeks.org/eventual-vs-strong-consistency-in-distributed-databases/)
+- [Consistency Patterns in Distributed Systems](https://cs.fyi/guide/consistency-patterns-week-strong-eventual/)

src/roadmaps/system-design/content/105-availability-patterns/index.md

@@ -2,7 +2,7 @@
 
 There are three Availability Patterns which are:
 
-- Fail-Over    
+- Fail-Over
 - Replication
 - Availability in Numbers