Kamran Ahmed
2 years ago
parent
cab06b46da
commit
ca35551e4f
12 changed files with 69 additions and 97 deletions
@ -1,6 +1,7 @@ |
||||
# 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. |
||||
After an update is made to the data, it is not guaranteed that any subsequent read operation will immediately reflect the changes made. The read may or may not see the recent write. |
||||
|
||||
To learn more, visit the following links: |
||||
|
||||
- [Consistency Patterns in Distributed Systems](https://cs.fyi/guide/consistency-patterns-week-strong-eventual/) |
||||
@ -1,7 +1,6 @@ |
||||
# 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. |
||||
|
||||
Eventual consistency is a form of Weak Consistency. After an update is made to the data, it will be eventually visible to any subsequent read operations. The data is replicated in an asynchronous manner, ensuring that all copies of the data are eventually updated. |
||||
|
||||
To learn more, visit the following links: |
||||
|
||||
|
||||
@ -1,6 +1,6 @@ |
||||
# 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. |
||||
After an update is made to the data, it will be immediately visible to any subsequent read operations. The data is replicated in a synchronous manner, ensuring that all copies of the data are updated at the same time. |
||||
|
||||
To learn more, visit the following links: |
||||
|
||||
|
||||
@ -1,34 +1,11 @@ |
||||
# Replication |
||||
|
||||
Replication is futher derived in two components: |
||||
Replication is an availability pattern that involves having multiple copies of the same data stored in different locations. In the event of a failure, the data can be retrieved from a different location. There are two main types of replication: Master-Master replication and Master-Slave replication. |
||||
|
||||
- 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. |
||||
- **Master-Master replication:** In this type of replication, multiple servers are configured as "masters," and each one can accept read and write operations. This allows for high availability and allows any of the servers to take over if one of them fails. However, this type of replication can lead to conflicts if multiple servers update the same data at the same time, so some conflict resolution mechanism is needed to handle this. |
||||
|
||||
- **Master-Slave replication:** In this type of replication, one server is designated as the "master" and handles all write operations, while multiple "slave" servers handle read operations. If the master fails, one of the slaves can be promoted to take its place. This type of replication is simpler to set up and maintain compared to Master-Master replication. |
||||
|
||||
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) |
||||
- [Replication: Avaiability Pattern](https://github.com/donnemartin/system-design-primer#replication) |
||||
@ -1,32 +1,5 @@ |
||||
# Availability Patterns |
||||
|
||||
There are three Availability Patterns which are: |
||||
Availability is measured as a percentage of uptime, and defines the proportion of time that a system is functional and working. Availability is affected by system errors, infrastructure problems, malicious attacks, and system load. Cloud applications typically provide users with a service level agreement (SLA), which means that applications must be designed and implemented to maximize availability. |
||||
|
||||
- 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) |
||||
- [System Design: Availability](https://dev.to/karanpratapsingh/system-design-availability-38bd) |
||||
- [Availability Patterns](https://learn.microsoft.com/en-us/azure/architecture/framework/resiliency/reliability-patterns#availability) |
||||
@ -1,11 +1,11 @@ |
||||
# Event Driven |
||||
|
||||
Event-driven architecture (EDA) is a design pattern that focuses on the flow of events through a system, rather than the flow of data or control. It is based on the idea that a system should respond to external events and trigger the appropriate actions. |
||||
Event-driven invocation uses a trigger to start the background task. Examples of using event-driven triggers include: |
||||
|
||||
In an event-driven system, events are generated by external sources, such as user input, sensors, or other systems, and are passed through the system to be handled by the appropriate components. These events can trigger various actions, such as updating the state of the system, sending a message to another system, or triggering a computation. |
||||
- The UI or another job places a message in a queue. The message contains data about an action that has taken place, such as the user placing an order. The background task listens on this queue and detects the arrival of a new message. It reads the message and uses the data in it as the input to the background job. This pattern is known as asynchronous message-based communication. |
||||
- The UI or another job saves or updates a value in storage. The background task monitors the storage and detects changes. It reads the data and uses it as the input to the background job. |
||||
- The UI or another job makes a request to an endpoint, such as an HTTPS URI, or an API that is exposed as a web service. It passes the data that is required to complete the background task as part of the request. The endpoint or web service invokes the background task, which uses the data as its input. |
||||
|
||||
Learn more from the following links: |
||||
|
||||
- [What is an Event-Driven Architecture?](https://aws.amazon.com/event-driven-architecture/) |
||||
- [Event-Driven Architecture - Everything You Need to Know](https://blog.hubspot.com/website/event-driven-architecture) |
||||
- [System Design: Event-Driven Architecture (EDA)](https://dev.to/karanpratapsingh/system-design-event-driven-architecture-eda-3m72) |
||||
- [Background Jobs - Event Driven Triggers](https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs#event-driven-triggers) |
||||
@ -1,15 +1,13 @@ |
||||
# Schedule Driven |
||||
|
||||
Schedule-driven systems are systems that are designed to perform specific tasks or actions at predetermined times or intervals. These schedules can be defined by the system itself or can be set by an external agent, such as a user or another system. |
||||
Schedule-driven invocation uses a timer to start the background task. Examples of using schedule-driven triggers include: |
||||
|
||||
Examples of schedule-driven systems include: |
||||
- A timer that is running locally within the application or as part of the application's operating system invokes a background task on a regular basis. |
||||
- A timer that is running in a different application, such as Azure Logic Apps, sends a request to an API or web service on a regular basis. The API or web service invokes the background task. |
||||
- A separate process or application starts a timer that causes the background task to be invoked once after a specified time delay, or at a specific time. |
||||
|
||||
- Cron jobs |
||||
- Scheduled batch jobs |
||||
- Recurring events |
||||
- Automated trading systems |
||||
Typical examples of tasks that are suited to schedule-driven invocation include batch-processing routines (such as updating related-products lists for users based on their recent behavior), routine data processing tasks (such as updating indexes or generating accumulated results), data analysis for daily reports, data retention cleanup, and data consistency checks. |
||||
|
||||
Learn more from the following links: |
||||
|
||||
- [System Design - Job Scheduling System?](https://aws.amazon.com/event-driven-architecture/) |
||||
- [Scheduler System Design](https://atul-agrawal.medium.com/scheduler-as-a-service-9c5d0414ec6d) |
||||
- [Schedule Driven - Background Jobs](https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs#schedule-driven-triggers) |
||||
@ -1,7 +1,7 @@ |
||||
# Returning Results |
||||
|
||||
Returning results in a system design refers to the process of providing the output or outcome of a specific task or action to the requesting entity. This can include providing a response to a user request, returning a result of a computation or analysis, or sending a notification or message to another system. |
||||
Background jobs execute asynchronously in a separate process, or even in a separate location, from the UI or the process that invoked the background task. Ideally, background tasks are "fire and forget" operations, and their execution progress has no impact on the UI or the calling process. This means that the calling process does not wait for completion of the tasks. Therefore, it cannot automatically detect when the task ends. |
||||
|
||||
Learn more from the following links: |
||||
|
||||
- [Overview of Return Statement](https://press.rebus.community/programmingfundamentals/chapter/return-statement/) |
||||
- [Returning Results - Background Jobs](https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs#returning-results) |
||||
Loading…
Reference in new issue