From cab06b46dae14564190d9a9befa209a6945bf0a4 Mon Sep 17 00:00:00 2001 From: Kamran Ahmed Date: Thu, 19 Jan 2023 16:45:34 +0400 Subject: [PATCH] Add content to system design roadmap --- .../101-how-to-approach-system-design.md | 9 +++++++-- .../100-introduction/102-who-is-this-guide-for.md | 4 +++- .../content/101-performance-vs-scalability.md | 6 +++--- .../content/102-latency-vs-throughput.md | 5 ++++- .../100-cap-theorem.md | 2 +- .../103-availability-vs-consistency/index.md | 13 +++++++------ .../100-weak-consistency.md | 4 +--- .../101-eventual-consistency.md | 3 +-- .../102-strong-consistency.md | 3 +-- .../content/105-availability-patterns/index.md | 2 +- 10 files changed, 29 insertions(+), 22 deletions(-) diff --git a/src/roadmaps/system-design/content/100-introduction/101-how-to-approach-system-design.md b/src/roadmaps/system-design/content/100-introduction/101-how-to-approach-system-design.md index b17dfc86c..1323eec61 100644 --- a/src/roadmaps/system-design/content/100-introduction/101-how-to-approach-system-design.md +++ b/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. \ No newline at end of file +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) \ No newline at end of file diff --git a/src/roadmaps/system-design/content/100-introduction/102-who-is-this-guide-for.md b/src/roadmaps/system-design/content/100-introduction/102-who-is-this-guide-for.md index 083fdbb5e..7d0d1b687 100644 --- a/src/roadmaps/system-design/content/100-introduction/102-who-is-this-guide-for.md +++ b/src/roadmaps/system-design/content/100-introduction/102-who-is-this-guide-for.md @@ -1 +1,3 @@ -# Who is this guide for \ No newline at end of file +# 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. \ No newline at end of file diff --git a/src/roadmaps/system-design/content/101-performance-vs-scalability.md b/src/roadmaps/system-design/content/101-performance-vs-scalability.md index fa30059de..1bc1d4e4f 100644 --- a/src/roadmaps/system-design/content/101-performance-vs-scalability.md +++ b/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: diff --git a/src/roadmaps/system-design/content/102-latency-vs-throughput.md b/src/roadmaps/system-design/content/102-latency-vs-throughput.md index 0ab7ad328..c8d498fbb 100644 --- a/src/roadmaps/system-design/content/102-latency-vs-throughput.md +++ b/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) \ No newline at end of file diff --git a/src/roadmaps/system-design/content/103-availability-vs-consistency/100-cap-theorem.md b/src/roadmaps/system-design/content/103-availability-vs-consistency/100-cap-theorem.md index 6febc1a02..849f824e2 100644 --- a/src/roadmaps/system-design/content/103-availability-vs-consistency/100-cap-theorem.md +++ b/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 diff --git a/src/roadmaps/system-design/content/103-availability-vs-consistency/index.md b/src/roadmaps/system-design/content/103-availability-vs-consistency/index.md index 430d189d7..e71dfe85c 100644 --- a/src/roadmaps/system-design/content/103-availability-vs-consistency/index.md +++ b/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/) \ No newline at end of file +- [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) \ No newline at end of file diff --git a/src/roadmaps/system-design/content/104-consistency-patterns/100-weak-consistency.md b/src/roadmaps/system-design/content/104-consistency-patterns/100-weak-consistency.md index 6c007e8b6..6a423aa8a 100644 --- a/src/roadmaps/system-design/content/104-consistency-patterns/100-weak-consistency.md +++ b/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/) \ No newline at end of file diff --git a/src/roadmaps/system-design/content/104-consistency-patterns/101-eventual-consistency.md b/src/roadmaps/system-design/content/104-consistency-patterns/101-eventual-consistency.md index afdb55819..96b9faed9 100644 --- a/src/roadmaps/system-design/content/104-consistency-patterns/101-eventual-consistency.md +++ b/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/) \ No newline at end of file +- [Consistency Patterns in Distributed Systems](https://cs.fyi/guide/consistency-patterns-week-strong-eventual/) \ No newline at end of file diff --git a/src/roadmaps/system-design/content/104-consistency-patterns/102-strong-consistency.md b/src/roadmaps/system-design/content/104-consistency-patterns/102-strong-consistency.md index 2faee7576..f451eaa79 100644 --- a/src/roadmaps/system-design/content/104-consistency-patterns/102-strong-consistency.md +++ b/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/) \ No newline at end of file +- [Consistency Patterns in Distributed Systems](https://cs.fyi/guide/consistency-patterns-week-strong-eventual/) \ No newline at end of file diff --git a/src/roadmaps/system-design/content/105-availability-patterns/index.md b/src/roadmaps/system-design/content/105-availability-patterns/index.md index e44b4c48d..bdaa7c815 100644 --- a/src/roadmaps/system-design/content/105-availability-patterns/index.md +++ b/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