mirror of
https://github.com/kamranahmedse/developer-roadmap.git
synced 2025-01-16 13:51:23 +01:00
Revamp system design content
This commit is contained in:
parent
c5f1e383c7
commit
7abe4ab91d
@ -3,6 +3,6 @@
|
||||
"enabled": false
|
||||
},
|
||||
"_variables": {
|
||||
"lastUpdateCheck": 1732419746256
|
||||
"lastUpdateCheck": 1734436957813
|
||||
}
|
||||
}
|
@ -451,7 +451,7 @@
|
||||
}
|
||||
},
|
||||
"zIndex": 999,
|
||||
"width": 200,
|
||||
"width": 150,
|
||||
"height": 40,
|
||||
"positionAbsolute": {
|
||||
"x": -226.10970787732015,
|
||||
|
@ -5347,4 +5347,4 @@
|
||||
"selected": false
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
@ -1,3 +0,0 @@
|
||||
# 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.
|
@ -1,17 +0,0 @@
|
||||
# RDBMS
|
||||
|
||||
A relational database like SQL is a collection of data items organized in tables. ACID is a set of properties of relational database transactions.
|
||||
|
||||
- **Atomicity** - Each transaction is all or nothing
|
||||
- **Consistency** - Any transaction will bring the database from one valid state to another
|
||||
- **Isolation** - Executing transactions concurrently has the same results as if the transactions were executed serially
|
||||
- **Durability** - Once a transaction has been committed, it will remain so
|
||||
|
||||
There are many techniques to scale a relational database: master-slave replication, master-master replication, federation, sharding, denormalization, and SQL tuning.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [@article@Is there a good reason I see VARCHAR(255) used so often?](https://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l)
|
||||
- [@article@How we optimized PostgreSQL queries 100x](https://towardsdatascience.com/how-we-optimized-postgresql-queries-100x-ff52555eabe?gi=13caf5bcf32e)
|
||||
- [@article@How do NULL values affect performance in a database search?](https://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search)
|
||||
- [@article@Slow Query Log](https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)
|
@ -1,15 +0,0 @@
|
||||
# NoSQL
|
||||
|
||||
NoSQL is a collection of data items represented in a key-value store, document store, wide column store, or a graph database. Data is denormalized, and joins are generally done in the application code. Most NoSQL stores lack true ACID transactions and favor eventual consistency.
|
||||
|
||||
BASE is often used to describe the properties of NoSQL databases. In comparison with the CAP Theorem, BASE chooses availability over consistency.
|
||||
|
||||
- Basically available - the system guarantees availability.
|
||||
- Soft state - the state of the system may change over time, even without input.
|
||||
- Eventual consistency - the system will become consistent over a period of time, given that the system doesn't receive input during that period.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Brief of NOSQL Patterns](http://horicky.blogspot.com/2009/11/nosql-patterns.html)
|
||||
- [@video@Introduction to NoSQL](https://www.youtube.com/watch?v=qI_g07C_Q5I)
|
||||
- [@feed@Explore top posts about NoSQL](https://app.daily.dev/tags/nosql?ref=roadmapsh)
|
@ -1,8 +0,0 @@
|
||||
# Caching Strategies
|
||||
|
||||
Since you can only store a limited amount of data in cache, you'll need to determine which cache update strategy works best for your use case. Here is the list of cache update strategies:
|
||||
|
||||
- Cache-aside
|
||||
- Write-through
|
||||
- Write-behind
|
||||
- Refresh-ahead
|
@ -1,9 +0,0 @@
|
||||
# Deployment Stamps
|
||||
|
||||
The deployment stamp pattern involves provisioning, managing, and monitoring a heterogeneous group of resources to host and operate multiple workloads or tenants. Each individual copy is called a stamp, or sometimes a service unit, scale unit, or cell. In a multi-tenant environment, every stamp or scale unit can serve a predefined number of tenants. Multiple stamps can be deployed to scale the solution almost linearly and serve an increasing number of tenants. This approach can improve the scalability of your solution, allow you to deploy instances across multiple regions, and separate your customer data.
|
||||
|
||||
To learn more visit the following links:
|
||||
|
||||
- [@article@Deployment Stamps pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/deployment-stamp)
|
||||
- [@article@Deployment Stamps 101](https://blog.devgenius.io/deployment-stamps-101-7c04a6f704a2)
|
||||
- [@feed@Explore top posts about CI/CD](https://app.daily.dev/tags/cicd?ref=roadmapsh)
|
@ -1,8 +0,0 @@
|
||||
# Geodes
|
||||
|
||||
The Geode pattern involves deploying a collection of backend services into a set of geographical nodes, each of which can service any request for any client in any region. This pattern allows serving requests in an active-active style, improving latency and increasing availability by distributing request processing around the globe.
|
||||
|
||||
To learn more visit the following links:
|
||||
|
||||
- [@article@Geode pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/geodes)
|
||||
- [@article@Geode Formation, Types & Appearance | What is a Geode?](https://study.com/academy/lesson/geode-formation-types-appearance.html)
|
@ -1,9 +0,0 @@
|
||||
# Health Endpoint Monitoring
|
||||
|
||||
Implement functional checks in an application that external tools can access through exposed endpoints at regular intervals. This can help to verify that applications and services are performing correctly.
|
||||
|
||||
To learn more visit the following links:
|
||||
|
||||
- [@article@Health Endpoint Monitoring pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/health-endpoint-monitoring)
|
||||
- [@article@Explaining the health endpoint monitoring pattern](https://www.oreilly.com/library/view/java-ee-8/9781788830621/5012c01e-90ca-4809-a210-d3736574f5b3.xhtml)
|
||||
- [@feed@Explore top posts about Monitoring](https://app.daily.dev/tags/monitoring?ref=roadmapsh)
|
@ -1,7 +0,0 @@
|
||||
# Queue-Based load leveling
|
||||
|
||||
Use a queue that acts as a buffer between a task and a service it invokes in order to smooth intermittent heavy loads that can cause the service to fail or the task to time out. This can help to minimize the impact of peaks in demand on availability and responsiveness for both the task and the service.
|
||||
|
||||
To learn more visit the following links:
|
||||
|
||||
- [@article@Queue-Based Load Leveling pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling)
|
@ -1,7 +0,0 @@
|
||||
# Throttling
|
||||
|
||||
Control the consumption of resources used by an instance of an application, an individual tenant, or an entire service. This can allow the system to continue to function and meet service level agreements, even when an increase in demand places an extreme load on resources.
|
||||
|
||||
To learn more visit the following links:
|
||||
|
||||
- [@article@Throttling pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/throttling)
|
@ -1,8 +0,0 @@
|
||||
# Bulkhead
|
||||
|
||||
The Bulkhead pattern is a type of application design that is tolerant of failure. In a bulkhead architecture, elements of an application are isolated into pools so that if one fails, the others will continue to function. It's named after the sectioned partitions (bulkheads) of a ship's hull. If the hull of a ship is compromised, only the damaged section fills with water, which prevents the ship from sinking.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Bulkhead pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead)
|
||||
- [@article@Get started with Bulkhead](https://dzone.com/articles/resilient-microservices-pattern-bulkhead-pattern)
|
@ -1,8 +0,0 @@
|
||||
# Circuit Breaker
|
||||
|
||||
Handle faults that might take a variable amount of time to recover from, when connecting to a remote service or resource. This can improve the stability and resiliency of an application.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Circuit breaker design pattern](https://en.wikipedia.org/wiki/Circuit_breaker_design_pattern)
|
||||
- [@article@Overview of Circuit Breaker](https://medium.com/geekculture/design-patterns-for-microservices-circuit-breaker-pattern-276249ffab33)
|
@ -1,9 +0,0 @@
|
||||
# Deployment Stamps
|
||||
|
||||
The deployment stamp pattern involves provisioning, managing, and monitoring a heterogeneous group of resources to host and operate multiple workloads or tenants. Each individual copy is called a stamp, or sometimes a service unit, scale unit, or cell. In a multi-tenant environment, every stamp or scale unit can serve a predefined number of tenants. Multiple stamps can be deployed to scale the solution almost linearly and serve an increasing number of tenants. This approach can improve the scalability of your solution, allow you to deploy instances across multiple regions, and separate your customer data.
|
||||
|
||||
To learn more visit the following links:
|
||||
|
||||
- [@article@Deployment Stamps pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/deployment-stamp)
|
||||
- [@article@Deployment Stamps 101](https://blog.devgenius.io/deployment-stamps-101-7c04a6f704a2)
|
||||
- [@feed@Explore top posts about CI/CD](https://app.daily.dev/tags/cicd?ref=roadmapsh)
|
@ -1,7 +0,0 @@
|
||||
# Geodes
|
||||
|
||||
The Geode pattern involves deploying a collection of backend services into a set of geographical nodes, each of which can service any request for any client in any region. This pattern allows serving requests in an active-active style, improving latency and increasing availability by distributing request processing around the globe.
|
||||
|
||||
To learn more visit the following links:
|
||||
|
||||
- [@article@Geode pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/geodes)
|
@ -1,8 +0,0 @@
|
||||
# Health Endpoint Monitoring
|
||||
|
||||
Implement functional checks in an application that external tools can access through exposed endpoints at regular intervals. This can help to verify that applications and services are performing correctly.
|
||||
|
||||
To learn more visit the following links:
|
||||
|
||||
- [@article@Health Endpoint Monitoring pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/health-endpoint-monitoring)
|
||||
- [@feed@Explore top posts about Monitoring](https://app.daily.dev/tags/monitoring?ref=roadmapsh)
|
@ -1,8 +0,0 @@
|
||||
# Bulkhead
|
||||
|
||||
The Bulkhead pattern is a type of application design that is tolerant of failure. In a bulkhead architecture, elements of an application are isolated into pools so that if one fails, the others will continue to function. It's named after the sectioned partitions (bulkheads) of a ship's hull. If the hull of a ship is compromised, only the damaged section fills with water, which prevents the ship from sinking.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Bulkhead pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead)
|
||||
- [@article@Get started with Bulkhead](https://dzone.com/articles/resilient-microservices-pattern-bulkhead-pattern)
|
@ -1,8 +0,0 @@
|
||||
# Circuit Breaker
|
||||
|
||||
Handle faults that might take a variable amount of time to recover from, when connecting to a remote service or resource. This can improve the stability and resiliency of an application.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Circuit breaker design pattern](https://en.wikipedia.org/wiki/Circuit_breaker_design_pattern)
|
||||
- [@article@Overview of Circuit Breaker](https://medium.com/geekculture/design-patterns-for-microservices-circuit-breaker-pattern-276249ffab33)
|
@ -1,8 +0,0 @@
|
||||
# Compensating Transaction
|
||||
|
||||
Undo the work performed by a series of steps, which together define an eventually consistent operation, if one or more of the steps fail. Operations that follow the eventual consistency model are commonly found in cloud-hosted applications that implement complex business processes and workflows.
|
||||
|
||||
Learn more from the following resources:
|
||||
|
||||
- [@article@Compensating Transaction pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction)
|
||||
- [@article@Intro to Compensation Transaction](https://en.wikipedia.org/wiki/Compensating_transaction)
|
@ -1,8 +0,0 @@
|
||||
# Health Endpoint Monitoring
|
||||
|
||||
Implement functional checks in an application that external tools can access through exposed endpoints at regular intervals. This can help to verify that applications and services are performing correctly.
|
||||
|
||||
To learn more visit the following links:
|
||||
|
||||
- [@article@Health Endpoint Monitoring pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/health-endpoint-monitoring)
|
||||
- [@feed@Explore top posts about Monitoring](https://app.daily.dev/tags/monitoring?ref=roadmapsh)
|
@ -1,7 +0,0 @@
|
||||
# Leader Election
|
||||
|
||||
Coordinate the actions performed by a collection of collaborating instances in a distributed application by electing one instance as the leader that assumes responsibility for managing the others. This can help to ensure that instances don't conflict with each other, cause contention for shared resources, or inadvertently interfere with the work that other instances are performing.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [@article@Leader Election Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/leader-election)
|
@ -1,7 +0,0 @@
|
||||
# Queue-Based load leveling
|
||||
|
||||
Use a queue that acts as a buffer between a task and a service it invokes in order to smooth intermittent heavy loads that can cause the service to fail or the task to time out. This can help to minimize the impact of peaks in demand on availability and responsiveness for both the task and the service.
|
||||
|
||||
To learn more visit the following links:
|
||||
|
||||
- [@article@Queue-Based Load Leveling pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling)
|
@ -1,7 +0,0 @@
|
||||
# Retry
|
||||
|
||||
Enable an application to handle transient failures when it tries to connect to a service or network resource, by transparently retrying a failed operation. This can improve the stability of the application.
|
||||
|
||||
Learn more from the following resources:
|
||||
|
||||
- [@article@Retry pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/retry)
|
@ -1,7 +0,0 @@
|
||||
# Scheduling Agent Supervisor
|
||||
|
||||
Coordinate a set of distributed actions as a single operation. If any of the actions fail, try to handle the failures transparently, or else undo the work that was performed, so the entire operation succeeds or fails as a whole. This can add resiliency to a distributed system, by enabling it to recover and retry actions that fail due to transient exceptions, long-lasting faults, and process failures.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Scheduler Agent Supervisor pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/scheduler-agent-supervisor)
|
@ -1,7 +0,0 @@
|
||||
# Federated Identity pattern
|
||||
|
||||
Delegate authentication to an external identity provider. This can simplify development, minimize the requirement for user administration, and improve the user experience of the application.
|
||||
|
||||
To learn more, visit the following links:
|
||||
|
||||
- [@article@Federated Identity pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/federated-identity)
|
@ -1,7 +0,0 @@
|
||||
# Gatekeeper
|
||||
|
||||
Protect applications and services using a dedicated host instance that acts as a broker between clients and the application or service, validates and sanitizes requests, and passes requests and data between them. This can provide an additional layer of security and limit the system's attack surface.
|
||||
|
||||
Learn more from the following resources:
|
||||
|
||||
- [@article@Gatekeeper pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/gatekeeper)
|
@ -1,7 +0,0 @@
|
||||
# Valet Key
|
||||
|
||||
Use a token that provides clients with restricted direct access to a specific resource, in order to offload data transfer from the application. This is particularly useful in applications that use cloud-hosted storage systems or queues, and can minimize cost and maximize scalability and performance.
|
||||
|
||||
Learn more from the following links:
|
||||
|
||||
- [@article@Valet Key pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/valet-key)
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user