Adding content to 104-consistency-patterns, 105-availability-patterns

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

@@ -1 +1,8 @@
-# Weak consistency
+# Weak Consistency
+
+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/)
+

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

@@ -1 +1,9 @@
-# Eventual consistency
+# Eventual Consistency
+
+After a write, reads will eventually see it (typically within milliseconds).Data is replicated asynchronously. This approach is seen in systems such as DNS and email. Eventual consistency works well in highly available systems.
+
+
+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/)

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

@@ -1 +1,8 @@
-# Strong consistency
+# Strong Consistency
+
+After a write, reads will see it. Data is replicated synchronously. This approach is seen in file systems and RDBMSes. Strong consistency works well in systems that need transactions.
+
+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/)

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

@@ -1 +1,16 @@
-# Consistency patterns
+# Consistency Patterns
+
+With multiple copies of the same data, we are faced with options on how to synchronize them so clients have a consistent view of the data. Recall the definition of consistency from the CAP theorem - Every read receives the most recent write or an error.
+
+## Weak Consistency:
+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.
+
+## Eventual Consistency:
+After a write, reads will eventually see it (typically within milliseconds). Data is replicated asynchronously. This approach is seen in systems such as DNS and email. Eventual consistency works well in highly available systems.
+
+## Strong Consistency:
+After a write, reads will see it. Data is replicated synchronously. This approach is seen in file systems and RDBMSes. Strong consistency works well in systems that need transactions.
+
+To learn more, visit the following links:
+- [Getting Started with Consistency Patterns](https://github.com/donnemartin/system-design-primer)
+- [Introduction to Consistency Patterns](https://iq.opengenus.org/consistency-patterns-in-system-design/)

src/roadmaps/system-design/content/105-availability-patterns/100-fail-over.md

@@ -1 +1,19 @@
-# Fail over
+# Fail-Over
+
+## Active-passive
+
+With active-passive fail-over, heartbeats are sent between the active and the passive server on standby. If the heartbeat is interrupted, the passive server takes over the active's IP address and resumes service.
+The length of downtime is determined by whether the passive server is already running in 'hot' standby or whether it needs to start up from 'cold' standby. Only the active server handles traffic. Active-passive failover can also be referred to as master-slave failover.
+
+## Active-active
+In active-active, both servers are managing traffic, spreading the load between them. If the servers are public-facing, the DNS would need to know about the public IPs of both servers. If the servers are internal-facing, application logic would need to know about both servers. Active-active failover can also be referred to as master-master failover.
+
+## Disadvantages of Failover
+
+ - Fail-over adds more hardware and additional complexity.
+ - There is a potential for loss of data if the active system fails before any newly written data can be replicated to the passive.
+
+ To learn more visit the following links:
+
+ - [Getting started with Fail-Over in System Design](https://github.com/donnemartin/system-design-primer)
+ - [System Design — Availabiliy Patterns](https://medium.com/must-know-computer-science/system-design-redundancy-and-replication-e9946aa335ba)

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

@@ -1 +1,34 @@
 # Replication
+
+Replication is futher derived in two components:
+
+ - Master-Slave Replication
+ - Master-Master Replication
+
+## Master-Slave Replication
+
+The master serves reads and writes, replicating writes to one or more slaves, which serve only reads. Slaves can also replicate to additional slaves in a tree-like fashion. If the master goes offline, the system can continue to operate in read-only mode until a slave is promoted to a master or a new master is provisioned.
+
+## Disadvantages Master-Slave replication
+
+Following are the disadvantages:
+ - Additional logic is needed to promote a slave to a master.
+
+## Master-Master Replication
+
+Both masters serve reads and writes and coordinate with each other on writes. If either master goes down, the system can continue to operate with both reads and writes.
+
+## Disadvantages of Master-Master replication
+
+Following are the disadvantages of master-master replication:
+
+ - A load balancer or you'll need to make changes to your application logic to determine where to write.
+ - Most master-master systems are either loosely consistent (violating ACID) or have increased write latency due to synchronization.
+ - Conflict resolution comes more into play as more write nodes are added and as latency increases.
+ - See Disadvantage(s): replication for points related to both master-slave and master-master.
+
+
+Visi the following links for more resources:
+
+- [Replication - Master-Slave](https://github.com/donnemartin/system-design-primer#master-slave-replication)
+- [Master- Master Replication](https://github.com/donnemartin/system-design-primer#master-master-replication)

src/roadmaps/system-design/content/105-availability-patterns/102-availability-in-numbers.md

@@ -1 +1,42 @@
-# Availability in numbers
+# Availability In Numbers
+
+Availability is often quantified by uptime (or downtime) as a percentage of time the service is available. Availability is generally measured in number of 9s--a service with 99.99% availability is described as having four 9s.
+
+## 99.9% Availability - Three 9s:
+
+| Duration           | Acceptable downtime |
+| -------------      | -------------       |
+| Downtime per year  | 8h 45min 57s        |
+| Downtime per month | 43m 49.7s           |
+| Downtime per week  | 10m 4.8s            |
+| Downtime per day   | 1m 26.4s            |
+
+## 99.99% Availability - Four 9s
+
+| Duration           | Acceptable downtime |
+| -------------      | -------------       |
+| Downtime per year  | 52min 35.7s         |
+| Downtime per month | 43m 49.7s           |
+| Downtime per week  | 1m 5s               |
+| Downtime per day   | 8.6s                |
+
+## Availability 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
+
+Overall availability decreases when two components with availability < 100% are in sequence:
+Availability (Total) = Availability (Foo) * Availability (Bar)
+If both Foo and Bar each had 99.9% availability, their total availability in sequence would be 99.8%.
+
+### In parallel
+
+Overall availability increases when two components with availability < 100% are in parallel:
+Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
+If both Foo and Bar each had 99.9% availability, their total availability in parallel would be 99.9999%.
+
+To learn more, visit the following links:
+
+- [Getting started with Availability in Numbers](https://github.com/donnemartin/system-design-primer)
+- [Availability in System Design](https://www.enjoyalgorithms.com/blog/availability-system-design-concept/)

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

@@ -1 +1,32 @@
-# Availability patterns
+# Availability Patterns
+
+There are three Availability Patterns which are:
+
+- Fail-Over    
+- Replication
+- Availability in Numbers
+
+## Fail-Over
+
+### Active-passive
+With active-passive fail-over, heartbeats are sent between the active and the passive server on standby. If the heartbeat is interrupted, the passive server takes over the active's IP address and resumes service.
+
+## Active-active
+In active-active, both servers are managing traffic, spreading the load between them. If the servers are public-facing, the DNS would need to know about the public IPs of both servers. If the servers are internal-facing, application logic would need to know about both servers. 
+
+## Replication
+
+Replication is futher derived in two components:
+
+ - Master-Slave Replication - The master serves reads and writes, replicating writes to one or more slaves, which serve only reads.
+ - Master-Master Replication - Both masters serve reads and writes and coordinate with each other on writes. If either master goes down, the system can continue to operate with both reads and writes.
+
+ ## Availability In Numbers
+
+Availability is often quantified by uptime (or downtime) as a percentage of time the service is available. Availability is generally measured in number of 9s--a service with 99.99% availability is described as having four 9s.
+
+To learn more, visit the following links:
+
+ - [Getting started with Availability Patterns](https://github.com/donnemartin/system-design-primer)
+ - [Availability in System Design](https://www.enjoyalgorithms.com/blog/availability-system-design-concept)
+ - []()