chore: sync content to repo (#10274)

Co-authored-by: nilbuild <4921183+nilbuild@users.noreply.github.com>
2026-09-19 09:32:03 +08:00 · 2026-09-04 10:17:37 +02:00
parent 82441f9718
commit e568d2cd13
106 changed files with 252 additions and 784 deletions
@@ -1,8 +1,6 @@
 # Ambassador
-
-Create helper services that send network requests on behalf of a consumer service or application. An ambassador service can be thought of as an out-of-process proxy that is co-located with the client.
-
-This pattern can be useful for offloading common client connectivity tasks such as monitoring, logging, routing, security (such as TLS), and resiliency patterns in a language agnostic way. It is often used with legacy applications, or other applications that are difficult to modify, in order to extend their networking capabilities. It can also enable a specialized team to implement those features.
+ 
+The ambassador pattern places a helper service in front of a client to handle networking concerns, like retries, monitoring, or protocol translation, on the client's behalf. This lets the main application focus on its core logic while the ambassador manages the complexity of communicating with external services. It is often implemented as a sidecar deployed alongside the client.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
-# Anti-corruption Layer
-
-Implement a facade or adapter layer between different subsystems that don't share the same semantics. This layer translates requests that one subsystem makes to the other subsystem. Use this pattern to ensure that an application's design is not limited by dependencies on outside subsystems. This pattern was first described by Eric Evans in Domain-Driven Design.
+# Anti-Corruption Layer
+ 
+An anti-corruption layer sits between two systems with different data models or logic, translating requests and responses so that one system's design does not leak into and pollute the other. It is often used when integrating a new system with a legacy system, keeping the new system's model clean and independent. This isolation makes it easier to later replace or evolve either system without affecting the other.

 Visit the following resources to learn more:

@@ -1,13 +1,6 @@
 # Application Caching
-
-In-memory caches such as Memcached and Redis are key-value stores between your application and your data storage. Since the data is held in RAM, it is much faster than typical databases where data is stored on disk. RAM is more limited than disk, so [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms) algorithms such as [least recently used (LRU)](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_\(LRU\)) can help invalidate 'cold' entries and keep 'hot' data in RAM.
-
-Redis has the following additional features:
-
-*   Persistence option
-*   Built-in data structures such as sorted sets and lists
-
-Generally, you should try to avoid file-based caching, as it makes cloning and auto-scaling more difficult.
+ 
+Application caching stores computed results or frequently used data directly within the application layer, often in memory, to avoid repeating expensive operations. It can cache anything from database query results to rendered page fragments. Because it lives close to the application code, it typically offers very low latency.

 Visit the following resources to learn more:

@@ -1,14 +1,6 @@
 # Application Layer
-
-Separating out the web layer from the application layer (also known as platform layer) allows you to scale and configure both layers independently. Adding a new API results in adding application servers without necessarily adding additional web servers. The single responsibility principle advocates for small and autonomous services that work together. Small teams with small services can plan more aggressively for rapid growth.
-
-![](https://i.imgur.com/F0cjurv.png)
-
-Disadvantages
-------------
-
-*   Adding an application layer with loosely coupled services requires a different approach from an architectural, operations, and process viewpoint (vs a monolithic system).
-*   Microservices can add complexity in terms of deployments and operations.
+ 
+The application layer is where the core business logic of a system runs, separate from the data storage layer and the presentation layer. Keeping this layer independent allows it to scale horizontally by running multiple instances behind a load balancer. It often gets broken down into smaller services, such as microservices, as a system grows.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
-# Asynchronous Request-Reply
-
-Decouple backend processing from a frontend host, where backend processing needs to be asynchronous, but the frontend still needs a clear response.
+# Async Request Reply
+ 
+The async request-reply pattern decouples a client's request from the actual processing time of a backend operation, useful when that operation takes longer than a typical HTTP request should wait for. The client gets an immediate acknowledgment along with a way to check status later, such as a polling endpoint or callback. This avoids holding a connection open for long-running operations.

 Visit the following resources to learn more:

@@ -1,11 +1,10 @@
 # Asynchronism
-
-Asynchronous workflows help reduce request times for expensive operations that would otherwise be performed in-line. They can also help by doing time-consuming work in advance, such as periodic aggregation of data.
+ 
+Asynchronism refers to designing a system so that operations do not have to complete in a strict sequence before moving on. Instead of waiting for a slow task to finish, the system can queue it up and continue handling other work. This approach improves responsiveness and throughput, especially for tasks that are slow or unpredictable in duration.

 Visit the following resources to learn more:

 - [@article@Patterns for microservices - Sync vs Async](https://medium.com/inspiredbrilliance/patterns-for-microservices-e57a2d71ff9e)
 - [@article@Applying back pressure when overloaded](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html)
 - [@article@Little's law](https://en.wikipedia.org/wiki/Little%27s_law)
- [@article@What is the difference between a message queue and a task queue?](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue-Why-would-a-task-queue-require-a-message-broker-like-RabbitMQ-Redis-Celery-or-IronMQ-to-function)
 - [@video@It's all a numbers game](https://www.youtube.com/watch?v=1KRYH75wgy4)
@@ -1,51 +1,6 @@
 # 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 41min 38s
-    Downtime per month | 43m 28s
-    Downtime per week  | 10m 4.8s
-    Downtime per day   | 1m 26s
-    
-
-99.99% Availability - Four 9s
-----------------------------
-
-    Duration           | Acceptable downtime
-    -------------      | -------------
-    Downtime per year  | 52min 9.8s
-    Downtime per month | 4m 21s
-    Downtime per week  | 1m 0.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%.
+ 
+Availability is often expressed as a percentage of uptime over a year, commonly referred to by the number of nines, such as 99.9% or 99.99%. Each additional nine represents significantly less allowed downtime per year, and pushing availability higher gets progressively harder and more expensive. This metric is used in service level agreements to set expectations with users.

 Visit the following resources to learn more:

@@ -1,8 +1,7 @@
 # Availability Monitoring
-
-A truly healthy system requires that the components and subsystems that compose the system are available. Availability monitoring is closely related to health monitoring. But whereas health monitoring provides an immediate view of the current health of the system, availability monitoring is concerned with tracking the availability of the system and its components to generate statistics about the uptime of the system.
+ 
+Availability monitoring tracks whether a system or service is reachable and responding to requests from the perspective of its users. It often involves synthetic checks that simulate real user requests from different locations to measure uptime. This differs from health monitoring in that it focuses on the end-to-end experience rather than individual components.

 Visit the following resources to learn more:

- [@article@Availability Monitoring](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring#availability-monitoring)
- [@feed@Explore top posts about Monitoring](https://app.daily.dev/tags/monitoring?ref=roadmapsh)
+- [@article@Availability Monitoring](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring#availability-monitoring)
@@ -1,10 +1,6 @@
 # Availability vs Consistency
-
-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.
-
-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.
-
-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.
+ 
+In a distributed system, availability and consistency often pull in opposite directions when a network partition happens. A system can either keep serving requests using potentially stale data, favoring availability, or refuse to respond until all nodes agree, favoring consistency. Which one a system prioritizes depends on the use case.

 Visit the following resources to learn more:

@@ -1,3 +1,3 @@
 # Back Pressure
-
-If queues start to grow significantly, the queue size can become larger than memory, resulting in cache misses, disk reads, and even slower performance. [Back pressure](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) can help by limiting the queue size, thereby maintaining a high throughput rate and good response times for jobs already in the queue. Once the queue fills up, clients get a server busy or HTTP 503 status code to try again later. Clients can retry the request at a later time, perhaps with [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff).
+ 
+Back pressure is a mechanism for controlling the flow of data or requests when a system component cannot keep up with incoming volume. Instead of letting a queue or buffer grow unbounded, the system slows down or rejects new work until the backlog clears. This protects downstream components from being overwhelmed and crashing.
@@ -1,8 +1,7 @@
 # Backends for Frontend
-
-Create separate backend services to be consumed by specific frontend applications or interfaces. This pattern is useful when you want to avoid customizing a single backend for multiple interfaces. This pattern was first described by Sam Newman.
+ 
+The backends for frontend pattern creates separate backend services tailored to the specific needs of different client types, such as mobile apps versus web browsers, rather than exposing one generic backend to all clients. Each backend can shape its API and responses to fit what that particular client needs. This avoids a single backend having to compromise between very different client requirements.

 Visit the following resources to learn more:

- [@article@Backends for Frontends pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends)
- [@feed@Explore top posts about Frontend Development](https://app.daily.dev/tags/frontend?ref=roadmapsh)
+- [@article@Backends for Frontends pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends)
@@ -1,13 +1,6 @@
 # Background Jobs
-
-Background jobs in system design refer to tasks that are executed in the background, independently of the main execution flow of the system. These tasks are typically initiated by the system itself, rather than by a user or another external agent.
-
-Background jobs can be used for a variety of purposes, such as:
-
-*   Performing maintenance tasks: such as cleaning up old data, generating reports, or backing up the database.
-*   Processing large volumes of data: such as data import, data export, or data transformation.
-*   Sending notifications or messages: such as sending email notifications or push notifications to users.
-*   Performing long-running computations: such as machine learning or data analysis.
+ 
+Background jobs are tasks that run outside the main request-response cycle of an application, so users are not stuck waiting for slow operations like sending emails or processing files. They can be triggered by events as they happen or run on a fixed schedule. Offloading this work keeps the application responsive to user-facing requests.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # 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.
+ 
+The bulkhead pattern isolates parts of a system into separate pools of resources, so that a failure or overload in one part does not consume the resources needed by other parts. It is named after the bulkheads in a ship's hull, which prevent a leak in one compartment from sinking the whole vessel. This containment limits how far a failure can spread.

 Visit the following resources to learn more:

@@ -1,8 +1,7 @@
 # Busy Database
-
-A busy database in system design refers to a database that is handling a high volume of requests or transactions, this can occur when a system is experiencing high traffic or when a database is not properly optimized for the workload it is handling. This can lead to Performance degradation, Increased resource utilization, Deadlocks and contention, Data inconsistencies. To address a busy database, a number of approaches can be taken such as Scaling out, Optimizing the schema, Caching, and Indexing.
+ 
+The busy database antipattern occurs when too much processing logic, such as complex computations or business rules, runs inside the database instead of the application layer. This overloads the database with work it is not optimized for and limits how well it can scale. Moving that logic into the application tier frees up the database to focus on data storage and retrieval.

 Visit the following resources to learn more:

- [@article@Busy Database antipattern](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/busy-database/)
- [@feed@Explore top posts about Database](https://app.daily.dev/tags/database?ref=roadmapsh)
+- [@article@Busy Database antipattern](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/busy-database/)
@@ -1,10 +1,7 @@
 # Busy Frontend
-
-A busy frontend happens when the user-facing part of the system — such as the web servers, CDN, or browser — is handling more work than it can efficiently manage. This can lead to slow page loads, delayed responses, or timeouts. Common causes include too many concurrent users, large static assets, heavy client-side rendering, or missing caching layers.
-
-To improve responsiveness, you can use CDNs to cache static files, optimize and lazy-load scripts, balance requests across multiple servers, and reduce unnecessary API calls. The goal is to make sure the frontend remains fast and responsive even under heavy traffic.
+ 
+The busy frontend antipattern happens when resource-intensive tasks that could run in the background are instead performed directly within a user-facing request, making the frontend do more work than necessary. This slows down response times for users and limits how many requests the frontend can handle concurrently. Offloading heavy work to background jobs keeps the frontend responsive.

 Visit the following resources to learn more:

- [@article@Busy Front End antipattern](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/busy-front-end/)
- [@feed@Explore top posts about Frontend Development](https://app.daily.dev/tags/frontend?ref=roadmapsh)
+- [@article@Busy Front End antipattern](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/busy-front-end/)
@@ -1,27 +1,6 @@
-# Cache-aside
-
-The application is responsible for reading and writing from storage. The cache does not interact with storage directly. The application does the following:
-
-*   Look for entry in cache, resulting in a cache miss
-    
-*   Load entry from the database
-    
-*   Add entry to cache
-    
-*   Return entry
-    
-      def get_user(self, user_id):
-        user = cache.get("user.{0}", user_id)
-        if user is None:
-            user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
-        if user is not None:
-            key = "user.{0}".format(user_id)
-            cache.set(key, json.dumps(user))
-        return user
-    
-[Memcached](https://memcached.org/) is generally used in this manner. Subsequent reads of data added to cache are fast. Cache-aside is also referred to as lazy loading. Only the requested data is cached, which avoids filling up the cache with data that isn't requested.
-
-![Cache Aside](https://i.imgur.com/Ujf0awN.png)
+# Cache-Aside
+ 
+Cache-aside, also called lazy loading, is a caching strategy where the application checks the cache first, and on a miss, fetches the data from the database and writes it into the cache for next time. This keeps the cache populated only with data that has actually been requested. The downside is that a cache miss adds extra latency for that particular request.

 Visit the following resources to learn more:

@@ -1,21 +1,6 @@
 # Caching
-
-Caching is the process of storing frequently accessed data in a temporary storage location, called a cache, in order to quickly retrieve it without the need to query the original data source. This can improve the performance of an application by reducing the number of times a data source must be accessed.
-
-There are several caching strategies:
-
-*   Refresh Ahead
-*   Write-Behind
-*   Write-through
-*   Cache Aside
-
-Also, you can have the cache in several places, examples include:
-
-*   Client Caching
-*   CDN Caching
-*   Web Server Caching
-*   Database Caching
-*   Application Caching
+ 
+Caching stores frequently accessed data in a fast-access layer, like memory, so subsequent requests can be served without repeating expensive computations or database queries. It reduces latency and load on backend systems, but introduces the challenge of keeping cached data consistent with the source of truth. Caches can exist at multiple points in a system, from the client to the database.

 Visit the following resources to learn more:

@@ -1,24 +1,6 @@
 # CAP Theorem
-
-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
-*   **Partition Tolerance** - The system continues to operate despite arbitrary partitioning due to network failures
-
-Networks aren't reliable, so you'll need to support partition tolerance. You'll need to make a software tradeoff between consistency and availability.
-
-CP - consistency and partition tolerance
----------------------------------------
-
-Waiting for a response from the partitioned node might result in a timeout error. CP is a good choice if your business needs require atomic reads and writes.
-
-AP - availability and partition tolerance
-----------------------------------------
-
-Responses return the most readily available version of the data available on any node, which might not be the latest. Writes might take some time to propagate when the partition is resolved.
-
-AP is a good choice if the business needs to allow for [eventual consistency](https://github.com/donnemartin/system-design-primer#eventual-consistency) or when the system needs to continue working despite external errors.
+ 
+The CAP theorem states that a distributed system can only guarantee two out of three properties at the same time: consistency, availability, and partition tolerance. Since network partitions are unavoidable in real systems, the practical choice comes down to consistency versus availability during a partition. Designers use CAP as a framework to reason about these trade-offs rather than as a strict rule for every scenario.

 Visit the following resources to learn more:

@@ -1,7 +1,3 @@
 # CDN Caching
-
-A Content Delivery Network (CDN) is a distributed network of servers that are strategically placed in various locations around the world. The main purpose of a CDN is to serve content to end-users with high availability and high performance by caching frequently accessed content on servers that are closer to the end-users.
-
-When a user requests content from a website that is using a CDN, the CDN will first check if the requested content is available in the cache of a nearby server. If the content is found in the cache, it is served to the user from the nearby server. If the content is not found in the cache, it is requested from the origin server (the original source of the content) and then cached on the nearby server for future requests.
-
-CDN caching can significantly improve the performance and availability of a website by reducing the distance that data needs to travel, reducing the load on the origin server, and allowing for faster delivery of content to end-users.
+ 
+CDN caching stores static content, like images, stylesheets, and scripts, on distributed edge servers close to end users. This reduces the distance data has to travel and offloads traffic from the origin server. Content can be cached for a set duration or invalidated when it changes.
@@ -1,12 +1,6 @@
 # Chatty I/O
-
-The cumulative effect of a large number of I/O requests can have a significant impact on performance and responsiveness.
-
-Network calls and other I/O operations are inherently slow compared to compute tasks. Each I/O request typically has significant overhead, and the cumulative effect of numerous I/O operations can slow down the system. Here are some common causes of chatty I/O.
-
-*   Reading and writing individual records to a database as distinct requests
-*   Implementing a single logical operation as a series of HTTP requests
-*   Reading and writing to a file on disk
+ 
+Chatty I/O refers to a pattern where an application makes many small, frequent calls to a resource, like a database or another service, instead of batching them into fewer, larger calls. Each individual call carries overhead, and this overhead adds up quickly at scale. Batching requests reduces the total number of round trips needed.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # Choreography
-
-Have each component of the system participate in the decision-making process about the workflow of a business transaction, instead of relying on a central point of control.
+ 
+Choreography is an approach to coordinating a distributed workflow where each service reacts to events and decides its own next action, rather than a central controller directing the process. Services publish events when they complete a step, and other services listen and respond accordingly. This keeps services loosely coupled but can make the overall flow harder to trace.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # 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.
+ 
+The circuit breaker pattern monitors calls to a remote service or resource and stops sending requests once failures cross a certain threshold, similar to an electrical circuit breaker tripping to prevent damage. While open, it fails fast instead of waiting on a service that is likely to fail anyway, and it periodically tests whether the service has recovered before resuming normal traffic. This prevents a failing dependency from slowing down or crashing the calling system.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Client Caching
-
-Client-side caching refers to the practice of storing frequently accessed data on the client's device rather than the server. This type of caching can help improve the performance of an application by reducing the number of times the client needs to request data from the server.
-
-One common example of client-side caching is web browsers caching frequently accessed web pages and resources. When a user visits a web page, the browser stores a copy of the page and its resources (such as images, stylesheets, and scripts) in the browser's cache. If the user visits the same page again, the browser can retrieve the cached version of the page and its resources instead of requesting them from the server, which can reduce the load time of the page.
-
-Another example of client-side caching is application-level caching. Some applications, such as mobile apps, can cache data on the client's device to improve performance and reduce the amount of data that needs to be transferred over the network.
-
-Client side caching has some advantages like reducing server load, faster page load times, and reducing network traffic. However, it also has some drawbacks like the potential for stale data if the client-side cache is not properly managed, or consuming memory or disk space on the client's device.
+ 
+Client caching stores data directly on the user's device, such as in a browser cache or local storage, so repeated requests for the same resource do not need to reach the server at all. This is the fastest form of caching, since it avoids network round trips entirely. Cache headers and expiration policies control how long client-cached content stays valid.

 Visit the following resources to learn more:

@@ -1,8 +1,7 @@
 # Cloud Design Patterns
-
-Cloud design patterns are solutions to common problems that arise when building systems that run on a cloud platform. These patterns provide a way to design and implement systems that can take advantage of the unique characteristics of the cloud, such as scalability, elasticity, and pay-per-use pricing. Some common cloud design patterns include Scalability, Elasticity, Fault Tolerance, Microservices, Serverless, Data Management, Front-end and Back-end separation and Hybrid.
+ 
+Cloud design patterns are reusable solutions to common problems encountered when building applications for cloud environments, covering areas like messaging, data management, and resiliency. These patterns address challenges specific to distributed, cloud-hosted systems, such as handling transient failures or coordinating between independently scaled services. Many originate from cloud provider documentation but apply broadly to any distributed system.

 Visit the following resources to learn more:

- [@article@Cloud Design Patterns](https://learn.microsoft.com/en-us/azure/architecture/patterns/)
- [@feed@Explore top posts about Cloud](https://app.daily.dev/tags/cloud?ref=roadmapsh)
+- [@article@Cloud Design Patterns](https://learn.microsoft.com/en-us/azure/architecture/patterns/)
@@ -1,3 +1,3 @@
 # Communication
-
-Network protocols are a key part of systems today, as no system can exist in isolation - they all need to communicate with each other. You should learn about the networking protocols such as HTTP, TCP, UDP. Also, learn about the architectural styles such as RPC, REST, GraphQL and gRPC.
+ 
+Communication in a distributed system covers the protocols and methods that different components use to exchange data with each other. The choice of communication method affects latency, reliability, and how tightly or loosely coupled the components are. Common approaches include HTTP-based APIs, remote procedure calls, and message-based protocols.
@@ -1,6 +1,6 @@
 # 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.
+ 
+A compensating transaction undoes the effects of a previous operation when a later step in a multi-step process fails, since distributed transactions cannot always be rolled back atomically like a single database transaction. Each step in the process has a corresponding compensating action defined in advance. This keeps the overall system consistent even when a workflow cannot complete as planned.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Consistency Patterns
-
-Consistency patterns refer to the ways in which data is stored and managed in a distributed system, and how that data is made available to users and applications. There are three main types of consistency patterns:
-
-*   Strong consistency
-*   Weak consistency
-*   Eventual Consistency
-
-Each of these patterns has its own advantages and disadvantages, and the choice of which pattern to use will depend on the specific requirements of the application or system.
+ 
+Consistency patterns describe how a distributed system keeps multiple copies of the same data in sync across nodes. Different patterns trade off how quickly all replicas reflect a write against how available the system stays during network issues. The common patterns are weak, eventual, and strong consistency, each suited to different types of applications.

 Visit the following resources to learn more:

@@ -1,11 +1,6 @@
 # Content Delivery Networks
-
-A content delivery network (CDN) is a globally distributed network of proxy servers, serving content from locations closer to the user. Generally, static files such as HTML/CSS/JS, photos, and videos are served from CDN, although some CDNs such as Amazon's CloudFront support dynamic content. The site's DNS resolution will tell clients which server to contact.
-
-Serving content from CDNs can significantly improve performance in two ways:
-
-*   Users receive content from data centers close to them
-*   Your servers do not have to serve requests that the CDN fulfills
+ 
+A Content Delivery Network, or CDN, is a network of geographically distributed servers that cache and serve content closer to users. By serving static assets like images, videos, and scripts from a nearby edge server, a CDN reduces latency and offloads traffic from the origin server. CDNs generally work as either pull or push based systems.

 Visit the following resources to learn more:

@@ -1,8 +1,7 @@
 # Data Management
-
-Data management is the key element of cloud applications, and influences most of the quality attributes. Data is typically hosted in different locations and across multiple servers for reasons such as performance, scalability or availability, and this can present a range of challenges. For example, data consistency must be maintained, and data will typically need to be synchronized across different locations.
+ 
+Data management patterns address how distributed systems store, access, and keep data consistent across multiple services or databases. This includes patterns for splitting data, keeping read-optimized views, and tracking changes over time. These patterns become important once a system moves beyond a single, shared database.

 Visit the following resources to learn more:

- [@article@Data management patterns](https://learn.microsoft.com/en-us/azure/architecture/patterns/category/data-management)
- [@feed@Explore top posts about Data Management](https://app.daily.dev/tags/data-management?ref=roadmapsh)
+- [@article@Data management patterns](https://learn.microsoft.com/en-us/azure/architecture/patterns/category/data-management)
@@ -1,6 +1,6 @@
 # Database Caching
-
-Database caching involves storing frequently accessed data from a database in a temporary storage location (the cache) to reduce the load on the database and improve application performance. Instead of repeatedly querying the database for the same data, the application first checks the cache. If the data is present (a cache hit), it's retrieved from the cache, which is much faster than a database query. If the data is not in the cache (a cache miss), the application queries the database, retrieves the data, stores it in the cache for future use, and then returns it to the application.
+ 
+Database caching stores the results of frequent or expensive database queries so they do not need to be recalculated on every request. Many databases include a built-in caching layer, and applications can also add an external cache in front of the database. This reduces load on the database and speeds up repeated reads.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Databases
-
-Picking the right database for a system is an important decision, as it can have a significant impact on the performance, scalability, and overall success of the system. Some of the key reasons why it's important to pick the right database include:
-
-*   Performance: Different databases have different performance characteristics, and choosing the wrong one can lead to poor performance and slow response times.
-*   Scalability: As the system grows and the volume of data increases, the database needs to be able to scale accordingly. Some databases are better suited for handling large amounts of data than others.
-*   Data Modeling: Different databases have different data modeling capabilities and choosing the right one can help to keep the data consistent and organized.
-*   Data Integrity: Different databases have different capabilities for maintaining data integrity, such as enforcing constraints, and can have different levels of data security.
-*   Support and maintenance: Some databases have more active communities and better documentation, making it easier to find help and resources.
+ 
+A database is a structured way to store, retrieve, and manage data for an application. Choosing a database involves deciding between relational and non-relational models, and understanding how it will scale, replicate, and stay consistent as the application grows. Database choice is one of the most consequential decisions in a system's design.

 Visit the following resources to learn more:

@@ -1,8 +1,6 @@
 # Denormalization
-
-Denormalization attempts to improve read performance at the expense of some write performance. Redundant copies of the data are written in multiple tables to avoid expensive joins. Some RDBMS such as PostgreSQL and Oracle support materialized views which handle the work of storing redundant information and keeping redundant copies consistent.
-
-Once data becomes distributed with techniques such as federation and sharding, managing joins across data centers further increases complexity. Denormalization might circumvent the need for such complex joins.
+ 
+Denormalization is the practice of adding redundant data to a database schema to reduce the number of joins needed for common queries. This trades some storage space and write complexity for faster reads, since related data can be fetched in a single query instead of several. It is a common technique when read performance matters more than storage efficiency.

 Visit the following resources to learn more:

@@ -5,5 +5,4 @@ The deployment stamp pattern involves provisioning, managing, and monitoring a h
 Visit the following resources to learn more:

 - [@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)
+- [@article@Deployment Stamps 101](https://blog.devgenius.io/deployment-stamps-101-7c04a6f704a2)
@@ -1,9 +1,8 @@
 # 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.
+ 
+The deployment stamps pattern deploys multiple independent copies, or stamps, of an application's infrastructure, each serving a subset of users or tenants. This limits the blast radius of a failure to a single stamp rather than the entire user base, and allows scaling by adding more stamps rather than growing one large deployment. It also makes it easier to meet regional or compliance requirements by isolating stamps geographically.

 Visit the following resources to learn more:

 - [@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)
+- [@article@Deployment Stamps 101](https://blog.devgenius.io/deployment-stamps-101-7c04a6f704a2)
@@ -1,8 +1,6 @@
 # Document Store
-
-A document store is centered around documents (XML, JSON, binary, etc), where a document stores all information for a given object. Document stores provide APIs or a query language to query based on the internal structure of the document itself. Note, many key-value stores include features for working with a value's metadata, blurring the lines between these two storage types.
-
-Based on the underlying implementation, documents are organized by collections, tags, metadata, or directories. Although documents can be organized or grouped together, documents may have fields that are completely different from each other.
+ 
+A document store saves data as documents, typically in formats like JSON or BSON, where each document can have a different structure. This flexibility suits applications with evolving or irregular data shapes, since there is no need to alter a fixed schema for every change. MongoDB is a widely used example of this database type.

 Visit the following resources to learn more:

@@ -1,24 +1,10 @@
 # Domain Name System
-
-A Domain Name System (DNS) translates a domain name such as [www.example.com](http://www.example.com) to an IP address.
-
-DNS is hierarchical, with a few authoritative servers at the top level. Your router or ISP provides information about which DNS server(s) to contact when doing a lookup. Lower level DNS servers cache mappings, which could become stale due to DNS propagation delays. DNS results can also be cached by your browser or OS for a certain period of time, determined by the time to live (TTL).
-
-*   NS record (name server) - Specifies the DNS servers for your domain/subdomain.
-*   MX record (mail exchange) - Specifies the mail servers for accepting messages.
-*   A record (address) - Points a name to an IP address.
-*   CNAME (canonical) - Points a name to another name or CNAME ([example.com](http://example.com) to [www.example.com](http://www.example.com)) or to an A record.
-
-Services such as [CloudFlare](https://www.cloudflare.com/dns/) and [Route53](https://aws.amazon.com/route53/) provide managed DNS services. Some DNS services can route traffic through various methods:
-
-    *   Prevent traffic from going to servers under maintenance
-    *   Balance between varying cluster sizes
-    *   A/B testing
+ 
+The Domain Name System, or DNS, translates human-readable domain names into the IP addresses computers use to route traffic. When a browser requests a website, it queries a DNS resolver that looks up the corresponding IP address before the connection can be made. DNS also supports features like load distribution and failover through techniques such as round-robin and health-checked records.

 Visit the following resources to learn more:

 - [@opensource@Getting started with Domain Name System](https://github.com/donnemartin/system-design-primer#domain-name-system)
 - [@article@What is DNS?](https://www.cloudflare.com/learning/dns/what-is-dns/)
 - [@article@Latency Based](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-latency)
- [@article@Geolocation Based](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-geo)
 - [@article@Weighted Round Robin](https://www.jscape.com/blog/load-balancing-algorithms)
@@ -1,10 +1,6 @@
-# Event Driven
-
-Event-driven invocation uses a trigger to start the background task. Examples of using event-driven triggers include:
-
-*   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.
+# Event-Driven
+ 
+An event-driven background job runs in response to something happening in the system, such as a new file upload or a user signing up. A message or event triggers the job asynchronously, decoupling the action that caused it from the processing that handles it. This pattern fits workloads where work needs to happen as soon as a trigger occurs.

 Visit the following resources to learn more:

@@ -1,9 +1,8 @@
 # Event Sourcing
-
-Instead of storing just the current state of the data in a domain, use an append-only store to record the full series of actions taken on that data. The store acts as the system of record and can be used to materialize the domain objects. This can simplify tasks in complex domains, by avoiding the need to synchronize the data model and the business domain, while improving performance, scalability, and responsiveness. It can also provide consistency for transactional data, and maintain full audit trails and history that can enable compensating actions.
+ 
+Event sourcing stores every change to an application's state as a sequence of immutable events, rather than storing just the current state. The current state can always be reconstructed by replaying the events in order, and the full history of changes is preserved. This provides a complete audit trail and makes it easier to debug how a system reached its current state.

 Visit the following resources to learn more:

 - [@article@Event Sourcing pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing)
- [@feed@Explore top posts about Architecture](https://app.daily.dev/tags/architecture?ref=roadmapsh)
- [@video@Event Sourcing Explained Using Football](https://www.youtube.com/watch?v=xPmQxYIi5fA&list=PLCl5BUbK0jXt5l18S5UNAoUc4eQ2PJDye)
+- [@video@Event Sourcing Explained Using Football](https://www.youtube.com/watch?v=xPmQxYIi5fA&list=PLCl5BUbK0jXt5l18S5UNAoUc4eQ2PJDye)
@@ -1,6 +1,6 @@
 # Eventual Consistency
-
-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.
+ 
+Eventual consistency guarantees that, given enough time without new writes, all replicas of the data will converge to the same value. Reads immediately after a write might return stale data, but the system resolves this over time. DNS and systems like Cassandra rely on this model to stay highly available.

 Visit the following resources to learn more:

@@ -1,13 +1,6 @@
 # Extraneous Fetching
-
-Extraneous fetching in system design refers to the practice of retrieving more data than is needed for a specific task or operation. This can occur when a system is not optimized for the specific workload or when the system is not properly designed to handle the data requirements.
-
-Extraneous fetching can lead to a number of issues, such as:
-
-*   Performance degradation
-*   Increased resource utilization
-*   Increased network traffic
-*   Poor user experience
+ 
+Extraneous fetching happens when an application retrieves more data than it actually needs for a given operation, wasting bandwidth and processing time. This often occurs from overly broad queries or APIs that always return full objects regardless of what the caller uses. Fetching only the required fields reduces unnecessary load on the system.

 Visit the following resources to learn more:

@@ -1,34 +1,6 @@
 # Fail-Over
-
-Failover is an availability pattern that is used to ensure that a system can continue to function in the event of a failure. It involves having a backup component or system that can take over in the event of a failure.
-
-In a failover system, there is a primary component that is responsible for handling requests, and a secondary (or backup) component that is on standby. The primary component is monitored for failures, and if it fails, the secondary component is activated to take over its duties. This allows the system to continue functioning with minimal disruption.
-
-Failover can be implemented in various ways, such as active-passive, active-active, and hot-standby.
-
-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.
+ 
+Fail-over is the process of automatically switching to a standby system or component when the active one fails. It can be active-passive, where the standby stays idle until needed, or active-active, where multiple systems handle traffic simultaneously and absorb the load of a failed node. Fail-over reduces downtime but adds complexity to detect failures and switch traffic reliably.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # Gateway Aggregation
-
-Use a gateway to aggregate multiple individual requests into a single request. This pattern is useful when a client must make multiple calls to different backend systems to perform an operation.
+ 
+Gateway aggregation combines multiple backend requests into a single request from the client's perspective, with the gateway making the individual calls to different services and merging the results. This reduces the number of round trips a client needs to make, which is especially useful for clients on slower networks, like mobile devices. It does add some coordination overhead at the gateway itself.

 Visit the following resources to learn more:

@@ -1,10 +1,6 @@
 # Gateway Routing
-
-Route requests to multiple services or multiple service instances using a single endpoint. The pattern is useful when you want to:
-
-*   Expose multiple services on a single endpoint and route to the appropriate service based on the request
-*   Expose multiple instances of the same service on a single endpoint for load balancing or availability purposes
-*   Expose differing versions of the same service on a single endpoint and route traffic across the different versions
+ 
+Gateway routing uses a single entry point to route incoming requests to different backend services based on the request's path, headers, or other attributes. This lets a system present a unified API to clients while internally splitting functionality across multiple services. It also makes it easier to change backend services without affecting how clients connect.

 Visit the following resources to learn more:

@@ -1,11 +1,8 @@
 # Graph Databases
-
-In a graph database, each node is a record and each arc is a relationship between two nodes. Graph databases are optimized to represent complex relationships with many foreign keys or many-to-many relationships.
-
-Graphs databases offer high performance for data models with complex relationships, such as a social network. They are relatively new and are not yet widely-used; it might be more difficult to find development tools and resources. Many graphs can only be accessed with REST APIs.
+ 
+A graph database stores data as nodes and edges, representing entities and the relationships between them. This structure is efficient for queries that involve traversing connections, such as finding mutual friends in a social network or recommending related products. Neo4j is one of the most widely used graph databases.

 Visit the following resources to learn more:

 - [@article@Graph database](https://en.wikipedia.org/wiki/Graph_database)
- [@video@Introduction to NoSQL](https://www.youtube.com/watch?v=qI_g07C_Q5I)
- [@feed@Explore top posts about Backend Development](https://app.daily.dev/tags/backend?ref=roadmapsh)
+- [@video@Introduction to NoSQL](https://www.youtube.com/watch?v=qI_g07C_Q5I)
@@ -1,9 +1,9 @@
 # GraphQL
-
-GraphQL is a query language and runtime for building APIs. It allows clients to define the structure of the data they need and the server will return exactly that. This is in contrast to traditional REST APIs, where the server exposes a fixed set of endpoints and the client must work with the data as it is returned.
+ 
+GraphQL is a query language for APIs that lets clients specify exactly which fields of data they need, rather than receiving a fixed structure from a fixed endpoint. This avoids the problem of over-fetching or under-fetching data common with REST APIs. A single GraphQL endpoint can serve many different client needs by adjusting the query.

 Visit the following resources to learn more:

+- [@roadmap@Visit the Dedicated GraphQL Roadmap](https://roadmap.sh/graphql)
 - [@article@GraphQL Server](https://www.howtographql.com/basics/3-big-picture/)
- [@article@What is GraphQL?](https://www.redhat.com/en/topics/api/what-is-graphql)
- [@feed@Explore top posts about GraphQL](https://app.daily.dev/tags/graphql?ref=roadmapsh)
+- [@article@What is GraphQL?](https://www.redhat.com/en/topics/api/what-is-graphql)
@@ -1,8 +1,7 @@
 # gRPC
-
-gRPC is a high-performance, open-source framework for building remote procedure call (RPC) APIs. It is based on the Protocol Buffers data serialization format and supports a variety of programming languages, including C#, Java, and Python.
+ 
+gRPC is a modern RPC framework developed by Google that uses HTTP/2 for transport and Protocol Buffers for serializing data. It supports features like streaming and bi-directional communication, and its binary format makes it faster and more compact than text-based protocols like JSON over HTTP. It is widely used for communication between microservices.

 Visit the following resources to learn more:

- [@article@What Is gRPC?](https://www.wallarm.com/what/the-concept-of-grpc)
- [@feed@Explore top posts about gRPC](https://app.daily.dev/tags/grpc?ref=roadmapsh)
+- [@article@What Is gRPC?](https://www.wallarm.com/what/the-concept-of-grpc)
@@ -1,9 +1,8 @@
 # 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.
+ 
+Health endpoint monitoring exposes a dedicated endpoint on a service that reports whether it is functioning correctly, often checking its own dependencies as part of the response. External systems, like load balancers or orchestration platforms, poll this endpoint to decide whether to route traffic to that instance. This gives an automated way to detect and react to unhealthy instances.

 Visit the following resources to learn more:

 - [@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)
+- [@article@Explaining the health endpoint monitoring pattern](https://www.oreilly.com/library/view/java-ee-8/9781788830621/5012c01e-90ca-4809-a210-d3736574f5b3.xhtml)
@@ -5,5 +5,4 @@ Implement functional checks in an application that external tools can access thr
 Visit the following resources to learn more:

 - [@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)
+- [@article@Explaining the health endpoint monitoring pattern](https://www.oreilly.com/library/view/java-ee-8/9781788830621/5012c01e-90ca-4809-a210-d3736574f5b3.xhtml)
@@ -5,5 +5,4 @@ Implement functional checks in an application that external tools can access thr
 Visit the following resources to learn more:

 - [@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)
+- [@article@Explaining the health endpoint monitoring pattern](https://www.oreilly.com/library/view/java-ee-8/9781788830621/5012c01e-90ca-4809-a210-d3736574f5b3.xhtml)
@@ -1,8 +1,7 @@
 # Health Monitoring
-
-A system is healthy if it is running and capable of processing requests. The purpose of health monitoring is to generate a snapshot of the current health of the system so that you can verify that all components of the system are functioning as expected.
+ 
+Health monitoring tracks whether individual components of a system are running and responding correctly, typically through periodic health check requests. A failing health check can trigger alerts or automatic actions, like removing an unhealthy instance from a load balancer's rotation. This is usually the most basic and immediate layer of monitoring.

 Visit the following resources to learn more:

- [@article@Health Monitoring of a System](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring#health-monitoring)
- [@feed@Explore top posts about Monitoring](https://app.daily.dev/tags/monitoring?ref=roadmapsh)
+- [@article@Health Monitoring of a System](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring#health-monitoring)
@@ -1,11 +1,3 @@
 # Horizontal Scaling
-
-Load balancers can also help with horizontal scaling, improving performance and availability. Scaling out using commodity machines is more cost efficient and results in higher availability than scaling up a single server on more expensive hardware, called Vertical Scaling. It is also easier to hire for talent working on commodity hardware than it is for specialized enterprise systems.
-
-Disadvantages of horizontal scaling
-----------------------------------
-
-*   Scaling horizontally introduces complexity and involves cloning servers
-    *   Servers should be stateless: they should not contain any user-related data like sessions or profile pictures
-    *   Sessions can be stored in a centralized data store such as a database (SQL, NoSQL) or a persistent cache (Redis, Memcached)
-*   Downstream servers such as caches and databases need to handle more simultaneous connections as upstream servers scale out.
+ 
+Horizontal scaling means adding more machines to a system to handle increased load, as opposed to vertical scaling, which adds more resources to an existing machine. It generally offers better fault tolerance, since the failure of one machine does not take down the entire system. Horizontal scaling requires a load balancer to distribute work across the added machines.
@@ -1,14 +1,6 @@
-# How To: System Design?
-
-There are several steps that can be taken when approaching a system design:
-
-*   **Understand the problem**: Gather information about the problem you are trying to solve and the requirements of the system. Identify the users and their needs, as well as any constraints or limitations of the system.
-*   **Identify the scope of the system:** Define the boundaries of the system, including what the system will do and what it will not do.
-*   **Research and analyze existing systems:** Look at similar systems that have been built in the past and identify what worked well and what didn't. Use this information to inform your design decisions.
-*   **Create a high-level design:** Outline the main components of the system and how they will interact with each other. This can include a rough diagram of the system's architecture, or a flowchart outlining the process the system will follow.
-*   **Refine the design:** As you work on the details of the design, iterate and refine it until you have a complete and detailed design that meets all the requirements.
-*   **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.
+# How to approach System Design?
+ 
+Approaching a system design problem starts with clarifying requirements: what the system needs to do, how many users it serves, and what scale it must handle. From there, the design moves through estimating capacity, sketching a high-level architecture, and drilling into individual components like databases, caches, and load balancers. Trade-offs get revisited throughout, since no design fits every constraint at once.

 Visit the following resources to learn more:

@@ -1,16 +1,6 @@
 # HTTP
-
-HTTP is a method for encoding and transporting data between a client and a server. It is a request/response protocol: clients issue requests and servers issue responses with relevant content and completion status info about the request. HTTP is self-contained, allowing requests and responses to flow through many intermediate routers and servers that perform load balancing, caching, encryption, and compression.
-
-A basic HTTP request consists of a verb (method) and a resource (endpoint). Below are common HTTP verbs:
-
-    Verb   | Description                   | Idempotent* | Safe | Cacheable                               |
-    -------|-------------------------------|-------------|------|-----------------------------------------|
-    GET    | Reads a resource              | Yes         | Yes  | Yes                                     |
-    POST   | Creates a resource or trigger | No          | No   | Yes if response contains freshness info |
-    PUT    | Creates or replace a resource | Yes         | No   | No                                      |
-    PATCH  | Partially updates a resource  | No          | No   | Yes if response contains freshness info |
-    DELETE | Deletes a resource            | Yes         | No   | No                                      |
+ 
+HTTP, or Hypertext Transfer Protocol, is the foundational protocol for communication on the web, defining how clients and servers exchange requests and responses. It is stateless, meaning each request is handled independently without relying on previous ones, and it uses methods like GET, POST, and PUT to define the type of operation. Most web APIs are built on top of HTTP.

 Visit the following resources to learn more:

@@ -1,8 +1,6 @@
 # Idempotent Operations
-
-Idempotent operations are operations that can be applied multiple times without changing the result beyond the initial application. In other words, if an operation is idempotent, it will have the same effect whether it is executed once or multiple times.
-
-It is also important to understand the benefits of [idempotent](https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning) operations, especially when using message or task queues that do not guarantee _exactly once_ processing. Many queueing systems guarantee _at least once_ message delivery or processing. These systems are not completely synchronized, for instance, across geographic regions, which simplifies some aspects of their implementation or design. Designing the operations that a task queue executes to be idempotent allows one to use a queueing system that has accepted this design trade-off.
+ 
+An idempotent operation produces the same result no matter how many times it is performed with the same input. This property matters in distributed systems because network failures often lead to retries, and an operation that is not idempotent could cause duplicate effects, like charging a customer twice. Designing operations to be idempotent makes retry logic safe.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # Instrumentation
-
-Instrumentation is a critical part of the monitoring process. You can make meaningful decisions about the performance and health of a system only if you first capture the data that enables you to make these decisions. The information that you gather by using instrumentation should be sufficient to enable you to assess performance, diagnose problems, and make decisions without requiring you to sign in to a remote production server to perform tracing (and debugging) manually. Instrumentation data typically comprises metrics and information that's written to trace logs.
+ 
+Instrumentation is the process of adding code to a system that emits data about its internal behavior, such as logs, metrics, and traces. Without instrumentation, there is no data for monitoring tools to collect or analyze. Good instrumentation is designed early, since retrofitting it into a complex system later is much harder.

 Visit the following resources to learn more:

@@ -1,9 +1,3 @@
 # Introduction
-
-System design is the process of defining the elements of a system, as well as their interactions and relationships, in order to satisfy a set of specified requirements.
-
-It involves taking a problem statement, breaking it down into smaller components and designing each component to work together effectively to achieve the overall goal of the system. This process typically includes analyzing the current system (if any) and determining any deficiencies, creating a detailed plan for the new system, and testing the design to ensure that it meets the requirements. It is an iterative process that may involve multiple rounds of design, testing, and refinement.
-
-In software engineering, system design is a phase in the software development process that focuses on the high-level design of a software system, including the architecture and components.
-
-It is also one of the important aspects of the interview process for software engineers. Most of the companies have a dedicated system design interview round, where they ask the candidates to design a system for a given problem statement. The candidates are expected to come up with a detailed design of the system, including the architecture, components, and their interactions. They are also expected to discuss the trade-offs involved in their design and the alternatives that they considered.
+ 
+This section covers the basics of system design: what it means to design a system, and how to think through the process before diving into specific components and patterns.
@@ -1,8 +1,6 @@
-# Key Value Store
-
-A key-value store generally allows for `O(1)` reads and writes and is often backed by memory or SSD. Data stores can maintain keys in lexicographic order, allowing efficient retrieval of key ranges. Key-value stores can allow for storing of metadata with a value.
-
-Key-value stores provide high performance and are often used for simple data models or for rapidly-changing data, such as an in-memory cache layer. Since they offer only a limited set of operations, complexity is shifted to the application layer if additional operations are needed.
+# Key-Value Store
+ 
+A key-value store organizes data as a simple collection of keys, each mapped to a value, with no fixed schema for the value's contents. This simplicity makes lookups by key very fast and the store easy to scale horizontally. Redis and DynamoDB are common examples, often used for caching or session storage.

 Visit the following resources to learn more:

@@ -1,8 +1,6 @@
 # Latency vs Throughput
-
-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.
+ 
+Latency is the time it takes to complete a single operation, such as the time between a request and its response. Throughput is the number of operations a system can process in a given time period. The two are related but not interchangeable: a system can have low latency but limited throughput, or high throughput with noticeable latency per request.

 Visit the following resources to learn more:

@@ -1,5 +1,3 @@
 # Layer 7 Load Balancing
-
-Layer 7 load balancers look at the application layer to decide how to distribute requests. This can involve contents of the header, message, and cookies. Layer 7 load balancers terminate network traffic, reads the message, makes a load-balancing decision, then opens a connection to the selected server. For example, a layer 7 load balancer can direct video traffic to servers that host videos while directing more sensitive user billing traffic to security-hardened servers.
-
-At the cost of flexibility, layer 4 load balancing requires less time and computing resources than Layer 7, although the performance impact can be minimal on modern commodity hardware.
+ 
+Layer 7 load balancing operates at the application layer of the network stack, meaning it can inspect the actual content of a request, such as the URL, headers, or cookies. This allows routing decisions based on the content of the request itself, like sending API traffic to one set of servers and image requests to another. It offers more flexibility than lower-layer balancing but requires more processing per request.
@@ -1,14 +1,6 @@
-# Load Balancer vs Reverse Proxy
-
-*   Deploying a load balancer is useful when you have multiple servers. Often, load balancers route traffic to a set of servers serving the same function.
-*   Reverse proxies can be useful even with just one web server or application server, opening up the benefits described in the previous section.
-*   Solutions such as NGINX and HAProxy can support both layer 7 reverse proxying and load balancing.
-
-Disadvantages of Reverse Proxy:
-------------------------------
-
-*   Introducing a reverse proxy results in increased complexity.
-*   A single reverse proxy is a single point of failure, configuring multiple reverse proxies (ie a failover) further increases complexity.
+# LB vs Reverse Proxy
+ 
+A load balancer and a reverse proxy both sit in front of backend servers, but they serve different primary purposes. A load balancer's main job is distributing traffic across multiple servers, while a reverse proxy's main job is forwarding requests to a backend and adding features like caching, compression, or SSL termination. In practice, many tools combine both roles.

 Visit the following resources to learn more:

@@ -1,23 +1,6 @@
 # Load Balancers
-
-Load balancers distribute incoming client requests to computing resources such as application servers and databases. In each case, the load balancer returns the response from the computing resource to the appropriate client. Load balancers are effective at:
-
-*   Preventing requests from going to unhealthy servers
-*   Preventing overloading resources
-*   Helping to eliminate a single point of failure
-
-Load balancers can be implemented with hardware (expensive) or with software such as HAProxy. Additional benefits include:
-
-*   **SSL termination** - Decrypt incoming requests and encrypt server responses so backend servers do not have to perform these potentially expensive operations
-    *   Removes the need to install X.509 certificates on each server
-*   **Session persistence** - Issue cookies and route a specific client's requests to same instance if the web apps do not keep track of sessions
-
-Disadvantages of load balancer
------------------------------
-
-*   The load balancer can become a performance bottleneck if it does not have enough resources or if it is not configured properly.
-*   Introducing a load balancer to help eliminate a single point of failure results in increased complexity.
-*   A single load balancer is a single point of failure, configuring multiple load balancers further increases complexity.
+ 
+A load balancer distributes incoming traffic across multiple servers so no single server becomes overwhelmed. It also improves availability, since traffic can be rerouted away from a failed server automatically. Load balancers can operate at different layers of the network stack and use various algorithms to decide where each request goes.

 Visit the following resources to learn more:

@@ -1,8 +1,6 @@
 # Load Balancing Algorithms
-
-A load balancer is a software or hardware device that keeps any one server from becoming overloaded. A load balancing algorithm is the logic that a load balancer uses to distribute network traffic between servers (an algorithm is a set of predefined rules).
-
-There are two primary approaches to load balancing. Dynamic load balancing uses algorithms that take into account the current state of each server and distribute traffic accordingly. Static load balancing distributes traffic without making these adjustments. Some static algorithms send an equal amount of traffic to each server in a group, either in a specified order or at random.
+ 
+Load balancing algorithms determine how a load balancer picks which server handles the next request. Common approaches include round robin, which cycles through servers in order, least connections, which sends traffic to the server with the fewest active requests, and IP hash, which routes based on the client's address. The right algorithm depends on how uniform the workload and server capacity are.

 Visit the following resources to learn more:

@@ -1,16 +1,10 @@
 # Message Queues
-
-Message queues receive, hold, and deliver messages. If an operation is too slow to perform inline, you can use a message queue with the following workflow:
-
-*   An application publishes a job to the queue, then notifies the user of job status
-*   A worker picks up the job from the queue, processes it, then signals the job is complete
-
-The user is not blocked and the job is processed in the background. During this time, the client might optionally do a small amount of processing to make it seem like the task has completed. For example, if posting a tweet, the tweet could be instantly posted to your timeline, but it could take some time before your tweet is actually delivered to all of your followers.
+ 
+A message queue is a component that receives, holds, and delivers messages between different parts of a system, allowing producers and consumers to operate independently of each other's speed or availability. Producers add messages to the queue, and consumers process them at their own pace. This decoupling improves reliability and lets each side scale independently.

 Visit the following resources to learn more:

 - [@article@What is Redis?](https://redis.io/)
 - [@article@RabbitMQ in Message Queues](https://www.rabbitmq.com/)
 - [@article@Overview of Amazon SQS](https://aws.amazon.com/sqs/)
- [@article@Apache Kafka](https://kafka.apache.org/)
- [@article@RabbitMQ for beginners](https://www.cloudamqp.com/blog/part1-rabbitmq-for-beginners-what-is-rabbitmq.html)
+- [@article@Apache Kafka](https://kafka.apache.org/)
@@ -1,6 +1,6 @@
 # Messaging
-
-Messaging is a pattern that allows for the communication and coordination between different components or systems, using messaging technologies such as message queues, message brokers, and event buses. This pattern allows for decoupling of the sender and receiver, and can be used to build scalable and flexible systems.
+ 
+Messaging patterns describe ways for components in a distributed system to communicate asynchronously through messages rather than direct calls. This includes patterns for sequencing messages, coordinating multiple consumers, and handling large payloads. Messaging decouples producers and consumers, letting each scale and fail independently.

 Visit the following resources to learn more:

@@ -1,12 +1,9 @@
 # Microservices
-
-Related to the "Application Layer" discussion are microservices, which can be described as a suite of independently deployable, small, modular services. Each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal. 1
-
-Pinterest, for example, could have the following microservices: user profile, follower, feed, search, photo upload, etc.
+ 
+Microservices is an architectural style where an application is built as a collection of small, independently deployable services, each responsible for a specific piece of functionality. Services communicate with each other over a network, typically through APIs or messaging. This approach makes it easier to scale, deploy, and update parts of a system independently, at the cost of added operational complexity.

 Visit the following resources to learn more:

 - [@article@Introduction to Microservices](https://aws.amazon.com/microservices/)
 - [@article@Microservices - Wikipedia](https://en.wikipedia.org/wiki/Microservices)
- [@article@Microservices](https://martinfowler.com/articles/microservices.html)
- [@feed@Explore top posts about Microservices](https://app.daily.dev/tags/microservices?ref=roadmapsh)
+- [@article@Microservices](https://martinfowler.com/articles/microservices.html)
@@ -1,8 +1,7 @@
 # Monitoring
-
-Distributed applications and services running in the cloud are, by their nature, complex pieces of software that comprise many moving parts. In a production environment, it's important to be able to track the way in which users use your system, trace resource utilization, and generally monitor the health and performance of your system. You can use this information as a diagnostic aid to detect and correct issues, and also to help spot potential problems and prevent them from occurring.
+ 
+Monitoring is the practice of collecting and analyzing data about a system's behavior to understand its health, performance, and usage over time. It covers everything from checking whether services are up to tracking detailed performance metrics and security events. Good monitoring lets teams detect and respond to problems before they become outages.

 Visit the following resources to learn more:

- [@article@Monitoring and Diagnostics Guidance](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring)
- [@feed@Explore top posts about Monitoring](https://app.daily.dev/tags/monitoring?ref=roadmapsh)
+- [@article@Monitoring and Diagnostics Guidance](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring)
@@ -1,12 +1,6 @@
 # No Caching
-
-No caching antipattern occurs when a cloud application that handles many concurrent requests, repeatedly fetches the same data. This can reduce performance and scalability.
-
-When data is not cached, it can cause a number of undesirable behaviors, including:
-
-*   Repeatedly fetching the same information from a resource that is expensive to access, in terms of I/O overhead or latency.
-*   Repeatedly constructing the same objects or data structures for multiple requests.
-*   Making excessive calls to a remote service that has a service quota and throttles clients past a certain limit.
+ 
+The no caching antipattern refers to an application that repeatedly performs expensive operations, like database queries or external API calls, without caching results that could be reused. This creates unnecessary load and latency for data that does not change often. Adding an appropriate caching layer can significantly reduce this overhead.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Noisy Neighbor
-
-Noisy neighbor refers to a situation in which one or more components of a system are utilizing a disproportionate amount of shared resources, leading to resource contention and reduced performance for other components. This can occur when a system is not properly designed or configured to handle the workload, or when a component is behaving unexpectedly.
-
-Examples of noisy neighbor scenarios include:
-
-*   One user on a shared server utilizing a large amount of CPU or memory, leading to reduced performance for other users on the same server.
-*   One process on a shared server utilizing a large amount of I/O, causing other processes to experience slow I/O and increased latency.
-*   One application consuming a large amount of network bandwidth, causing other applications to experience reduced throughput.
+ 
+The noisy neighbor problem occurs when one tenant or workload on a shared resource consumes a disproportionate amount of capacity, degrading performance for other tenants sharing the same infrastructure. It commonly shows up in multi-tenant systems or shared cloud infrastructure. Solutions include resource quotas, throttling, and isolating workloads onto separate resources.

 Visit the following resources to learn more:

@@ -1,15 +1,7 @@
 # Performance Antipatterns
-
-Performance antipatterns in system design refer to common mistakes or suboptimal practices that can lead to poor performance in a system. These patterns can occur at different levels of the system and can be caused by a variety of factors such as poor design, lack of optimization, or lack of understanding of the workload.
-
-Some of the examples of performance antipatterns include:
-
-*   **N+1 queries:** This occurs when a system makes multiple queries to a database to retrieve related data, instead of using a single query to retrieve all the necessary data.
-*   **Chatty interfaces:** This occurs when a system makes too many small and frequent requests to an external service or API, instead of making fewer, larger requests.
-*   **Unbounded data:** This occurs when a system retrieves or processes more data than is necessary for the task at hand, leading to increased resource usage and reduced performance.
-*   **Inefficient algorithms:** This occurs when a system uses an algorithm that is not well suited to the task at hand, leading to increased resource usage and reduced performance.
+ 
+Performance antipatterns are common design mistakes that lead to poor performance or scalability in a system, even when the code appears to work correctly. Recognizing these patterns, such as unnecessary synchronous calls or repeated database queries, helps engineers avoid bottlenecks before they show up in production. Many of these patterns become visible only under load.

 Visit the following resources to learn more:

- [@article@Performance antipatterns for cloud applications](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/)
- [@feed@Explore top posts about Performance](https://app.daily.dev/tags/performance?ref=roadmapsh)
+- [@article@Performance antipatterns for cloud applications](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/)
@@ -1,8 +1,7 @@
 # Performance Monitoring
-
-As the system is placed under more and more stress (by increasing the volume of users), the size of the datasets that these users access grows and the possibility of failure of one or more components becomes more likely. Frequently, component failure is preceded by a decrease in performance. If you're able detect such a decrease, you can take proactive steps to remedy the situation.
+ 
+Performance monitoring tracks metrics like response time, throughput, and resource usage to understand how well a system is performing under real conditions. It helps identify bottlenecks, slow endpoints, or degrading trends before they cause noticeable problems for users. This data is often visualized on dashboards for ongoing observation.

 Visit the following resources to learn more:

- [@article@Performance Monitoring](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring#performance-monitoring)
- [@feed@Explore top posts about Monitoring](https://app.daily.dev/tags/monitoring?ref=roadmapsh)
+- [@article@Performance Monitoring](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring#performance-monitoring)
@@ -1,15 +1,9 @@
 # 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.
-
-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.
+ 
+Performance and scalability describe different problems in a system. A performance problem shows up when a system is slow for a single user, while a scalability problem shows up when the system is fast for one user but slows down under heavy load. A system can be fast but not scalable, or scalable but not particularly fast for any individual request.

 Visit the following resources to learn more:

 - [@article@Scalability, Availability & Stability Patterns](https://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
 - [@article@A Word on Scalability](https://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
- [@article@Performance vs Scalability](https://blog.professorbeekums.com/performance-vs-scalability/)
- [@feed@Explore top posts about Performance](https://app.daily.dev/tags/performance?ref=roadmapsh)
+- [@article@Performance vs Scalability](https://blog.professorbeekums.com/performance-vs-scalability/)
@@ -1,6 +1,6 @@
-# Publisher Subscriber
-
-Enable an application to announce events to multiple interested consumers asynchronously, without coupling the senders to the receivers.
+# Publisher/Subscriber
+ 
+The publisher/subscriber pattern lets a component, the publisher, broadcast messages to multiple subscribers without knowing who or how many are listening. Subscribers register interest in certain types of messages and receive them as they are published. This decouples producers from consumers entirely, since neither needs direct knowledge of the other.

 Visit the following resources to learn more:

@@ -1,8 +1,6 @@
 # Pull CDNs
-
-Pull CDNs grab new content from your server when the first user requests the content. You leave the content on your server and rewrite URLs to point to the CDN. This results in a slower request until the content is cached on the CDN.
-
-A time-to-live (TTL) determines how long content is cached. Pull CDNs minimize storage space on the CDN, but can create redundant traffic if files expire and are pulled before they have actually changed. Sites with heavy traffic work well with pull CDNs, as traffic is spread out more evenly with only recently-requested content remaining on the CDN.
+ 
+A pull CDN fetches content from the origin server the first time a user requests it, then caches that content for subsequent requests until it expires. This keeps the CDN in sync with the origin automatically, since new or updated content gets pulled in on demand. It works well for sites with content that changes often but is not accessed instantly after publishing.

 Visit the following resources to learn more:

@@ -1,8 +1,6 @@
 # Push CDNs
-
-Push CDNs receive new content whenever changes occur on your server. You take full responsibility for providing content, uploading directly to the CDN and rewriting URLs to point to the CDN. You can configure when content expires and when it is updated. Content is uploaded only when it is new or changed, minimizing traffic, but maximizing storage.
-
-Sites with a small amount of traffic or sites with content that isn't often updated work well with push CDNs. Content is placed on the CDNs once, instead of being re-pulled at regular intervals.
+ 
+A push CDN requires the origin server to actively upload content to the CDN ahead of time, rather than waiting for a request. This suits sites with relatively small amounts of content that does not change frequently, since it gives full control over what gets stored and when it updates. It is less efficient for large, frequently changing content libraries.

 Visit the following resources to learn more:

@@ -1,15 +1,6 @@
-# Refresh-ahead
-
-You can configure the cache to automatically refresh any recently accessed cache entry prior to its expiration.
-
-Refresh-ahead can result in reduced latency vs read-through if the cache can accurately predict which items are likely to be needed in the future.
-
-Disadvantage of refresh-ahead:
------------------------------
-
-*   Not accurately predicting which items are likely to be needed in the future can result in reduced performance than without refresh-ahead.
-
-![](https://i.imgur.com/sBXb7lb.png)
+# Refresh Ahead
+ 
+Refresh-ahead is a caching strategy where the system automatically refreshes a cached item before it expires, based on predicted access patterns. This can reduce latency for frequently accessed data by avoiding cache misses altogether. It works best when access patterns are predictable, since refreshing rarely used data wastes resources.

 Visit the following resources to learn more:

@@ -1,10 +1,6 @@
 # Replication
-
-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-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.
+ 
+Replication means keeping copies of the same data or service on multiple servers. It improves availability, since a failure on one node does not take down the whole system, and it can improve read performance by spreading requests across replicas. Replication introduces its own challenge of keeping the copies consistent with each other.

 Visit the following resources to learn more:

@@ -1,13 +1,3 @@
 # Replication
-
-Replication is the process of copying data from one database to another. Replication is used to increase availability and scalability of databases. There are two types of replication: master-slave and master-master.
-
-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.
-
-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.
+ 
+Replication means keeping copies of the same data or service on multiple servers. It improves availability, since a failure on one node does not take down the whole system, and it can improve read performance by spreading requests across replicas. Replication introduces its own challenge of keeping the copies consistent with each other.
@@ -1,10 +1,6 @@
-# Resilience
-
-Resiliency is the ability of a system to gracefully handle and recover from failures, both inadvertent and malicious.
-
-The nature of cloud hosting, where applications are often multi-tenant, use shared platform services, compete for resources and bandwidth, communicate over the Internet, and run on commodity hardware means there is an increased likelihood that both transient and more permanent faults will arise. The connected nature of the internet and the rise in sophistication and volume of attacks increase the likelihood of a security disruption.
-
-Detecting failures and recovering quickly and efficiently, is necessary to maintain resiliency.
+# Resiliency
+ 
+Resiliency is a system's ability to recover from failures and continue operating, rather than failing completely when something goes wrong. It involves designing components to detect failures quickly, contain their impact, and recover automatically where possible. Patterns like circuit breakers, retries, and bulkheads all contribute to overall system resiliency.

 Visit the following resources to learn more:

@@ -1,18 +1,9 @@
 # REST
-
-REST is an architectural style enforcing a client/server model where the client acts on a set of resources managed by the server. The server provides a representation of resources and actions that can either manipulate or get a new representation of resources. All communication must be stateless and cacheable.
-
-There are four qualities of a RESTful interface:
-
-*   Identify resources (URI in HTTP) - use the same URI regardless of any operation.
-*   Change with representations (Verbs in HTTP) - use verbs, headers, and body.
-*   Self-descriptive error message (status response in HTTP) - Use status codes, don't reinvent the wheel.
-*   HATEOAS (HTML interface for HTTP) - your web service should be fully accessible in a browser.
-
-REST is focused on exposing data. It minimizes the coupling between client/server and is often used for public HTTP APIs. REST uses a more generic and uniform method of exposing resources through URIs, representation through headers, and actions through verbs such as GET, POST, PUT, DELETE, and PATCH. Being stateless, REST is great for horizontal scaling and partitioning.
+ 
+REST, or Representational State Transfer, is an architectural style for designing APIs around resources, identified by URLs, that clients interact with using standard HTTP methods. It emphasizes statelessness, meaning each request contains all the information needed to process it. REST is one of the most common approaches for building web APIs.

 Visit the following resources to learn more:

+- [@roadmap@Visit the Dedicated API Design Roadmap Roadmap](https://roadmap.sh/api-design)
 - [@opensource@What Is REST?](https://github.com/donnemartin/system-design-primer#representational-state-transfer-rest)
- [@article@What are the drawbacks of using RESTful APIs?](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs)
- [@feed@Explore top posts about REST API](https://app.daily.dev/tags/rest-api?ref=roadmapsh)
+- [@article@What are the drawbacks of using RESTful APIs?](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs)
@@ -1,6 +1,6 @@
 # Retry Storm
-
-Retry Storm refers to a situation in which a large number of retries are triggered in a short period of time, leading to a significant increase in traffic and resource usage. This can occur when a system is not properly designed to handle failures or when a component is behaving unexpectedly. This can lead to Performance degradation, Increased resource utilization, Increased network traffic, and Poor user experience. To address retry storms, a number of approaches can be taken such as Exponential backoff, Circuit breaking, and Monitoring and alerting.
+ 
+A retry storm happens when many clients or services retry failed requests at the same time, often after a shared dependency recovers from an outage, overwhelming that dependency again right after it comes back up. This can turn a brief failure into a prolonged outage. Techniques like exponential backoff and jitter help spread out retries to avoid this.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # 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.
+ 
+The retry pattern automatically re-attempts a failed operation, under the assumption that many failures in distributed systems are transient and will succeed if tried again shortly after. Retries are usually combined with strategies like exponential backoff to avoid overwhelming a struggling service. Care is needed to ensure the retried operation is safe to repeat, ideally by making it idempotent.

 Visit the following resources to learn more:

@@ -1,38 +1,7 @@
 # RPC
-
-In an RPC, a client causes a procedure to execute on a different address space, usually a remote server. The procedure is coded as if it were a local procedure call, abstracting away the details of how to communicate with the server from the client program. Remote calls are usually slower and less reliable than local calls so it is helpful to distinguish RPC calls from local calls. Popular RPC frameworks include [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/), and [Avro](https://avro.apache.org/docs/current/).
-
-RPC is a request-response protocol:
-
-*   Client program - Calls the client stub procedure. The parameters are pushed onto the stack like a local procedure call.
-*   Client stub procedure - Marshals (packs) procedure id and arguments into a request message.
-*   Client communication module - OS sends the message from the client to the server.
-*   Server communication module - OS passes the incoming packets to the server stub procedure.
-*   Server stub procedure - Unmarshalls the results, calls the server procedure matching the procedure id and passes the given arguments.
-*   The server response repeats the steps above in reverse order.
-
-Sample RPC calls:
-
-    GET /someoperation?data=anId
-    
-    POST /anotheroperation
-    {
-      "data":"anId";
-      "anotherdata": "another value"
-    }
-    
-
-RPC is focused on exposing behaviors. RPCs are often used for performance reasons with internal communications, as you can hand-craft native calls to better fit your use cases.
-
-Disadvantage of RPC
-------------------
-
-*   RPC clients become tightly coupled to the service implementation.
-*   A new API must be defined for every new operation or use case.
-*   It can be difficult to debug RPC.
-*   You might not be able to leverage existing technologies out of the box. For example, it might require additional effort to ensure [RPC calls are properly cached](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) on caching servers such as [Squid](http://www.squid-cache.org/).
+ 
+Remote Procedure Call, or RPC, lets a program call a function on a remote server as if it were a local function call, hiding the details of the network communication involved. The client sends the function name and arguments, the server executes the function, and the result gets sent back. RPC is commonly used for internal service-to-service communication.

 Visit the following resources to learn more:

- [@opensource@What Is RPC?](https://github.com/donnemartin/system-design-primer#remote-procedure-call-rpc)
- [@feed@Explore top posts about Backend Development](https://app.daily.dev/tags/backend?ref=roadmapsh)
+- [@opensource@What Is RPC?](https://github.com/donnemartin/system-design-primer#remote-procedure-call-rpc)
@@ -1,12 +1,6 @@
 # Schedule Driven
-
-Schedule-driven invocation uses a timer to start the background task. Examples of using schedule-driven triggers 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.
-
-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.
+ 
+A schedule driven background job runs at fixed times or intervals, regardless of whether a specific event has occurred. Cron jobs are a common example, running tasks like nightly reports or periodic cleanups. This approach fits recurring maintenance work rather than work tied to a specific user action.

 Visit the following resources to learn more:

@@ -1,14 +1,7 @@
 # Security Monitoring
-
-All commercial systems that include sensitive data must implement a security structure. The complexity of the security mechanism is usually a function of the sensitivity of the data. In a system that requires users to be authenticated, you should record:
-
-*   All sign-in attempts, whether they fail or succeed.
-*   All operations performed by—and the details of all resources accessed by—an authenticated user.
-*   When a user ends a session and signs out.
-
-Monitoring might be able to help detect attacks on the system. For example, a large number of failed sign-in attempts might indicate a brute-force attack. An unexpected surge in requests might be the result of a distributed denial-of-service (DDoS) attack. You must be prepared to monitor all requests to all resources regardless of the source of these requests. A system that has a sign-in vulnerability might accidentally expose resources to the outside world without requiring a user to actually sign in.
+ 
+Security monitoring tracks events related to the security of a system, such as failed login attempts, unusual access patterns, or potential intrusions. It helps detect and respond to threats in real time, rather than discovering a breach after the fact. This often feeds into automated alerting or incident response processes.

 Visit the following resources to learn more:

- [@article@Security Monitoring](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring#security-monitoring)
- [@feed@Explore top posts about Monitoring](https://app.daily.dev/tags/monitoring?ref=roadmapsh)
+- [@article@Security Monitoring](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring#security-monitoring)
@@ -4,5 +4,4 @@ Security provides confidentiality, integrity, and availability assurances agains

 Visit the following resources to learn more:

- [@article@Security patterns](https://learn.microsoft.com/en-us/azure/architecture/framework/security/security-patterns)
- [@feed@Explore top posts about Security](https://app.daily.dev/tags/security?ref=roadmapsh)
+- [@article@Security patterns](https://learn.microsoft.com/en-us/azure/architecture/framework/security/security-patterns)
@@ -1,6 +1,6 @@
 # Service Discovery
-
-Systems such as [Consul](https://www.consul.io/docs/index.html), [Etcd](https://coreos.com/etcd/docs/latest), and [Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) can help services find each other by keeping track of registered names, addresses, and ports. [Health checks](https://www.consul.io/intro/getting-started/checks.html) help verify service integrity and are often done using an HTTP endpoint. Both Consul and Etcd have a built in key-value store that can be useful for storing config values and other shared data.
+ 
+Service discovery is the mechanism that lets services in a distributed system find each other's network locations without hardcoding IP addresses. As services scale up, down, or move between hosts, a service discovery system keeps track of where each instance currently lives. Tools like Consul, etcd, or built-in mechanisms in orchestration platforms handle this automatically.

 Visit the following resources to learn more:

@@ -1,11 +1,8 @@
 # Sharding
-
-Sharding distributes data across different databases such that each database can only manage a subset of the data. Taking a users database as an example, as the number of users increases, more shards are added to the cluster.
-
-Similar to the advantages of federation, sharding results in less read and write traffic, less replication, and more cache hits. Index size is also reduced, which generally improves performance with faster queries. If one shard goes down, the other shards are still operational, although you'll want to add some form of replication to avoid data loss. Like federation, there is no single central master serializing writes, allowing you to write in parallel with increased throughput.
+ 
+Sharding splits a database horizontally, distributing rows of the same table across multiple database servers based on a shard key, such as user ID. Each shard holds a subset of the total data, which allows the system to scale beyond what a single server could handle. Choosing a good shard key is critical, since a poor choice can lead to uneven load across shards.

 Visit the following resources to learn more:

 - [@article@The coming of the Shard](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html)
- [@article@Shard (database architecture)](https://en.wikipedia.org/wiki/Shard_(database_architecture))
- [@feed@Explore top posts about Backend Development](https://app.daily.dev/tags/backend?ref=roadmapsh)
+- [@article@Shard (database architecture)](https://en.wikipedia.org/wiki/Shard_(database_architecture))
@@ -1,8 +1,7 @@
 # Sharding
-
-Sharding is a technique used to horizontally partition a large data set across multiple servers, in order to improve the performance, scalability, and availability of a system. This is done by breaking the data set into smaller chunks, called shards, and distributing the shards across multiple servers. Each shard is self-contained and can be managed and scaled independently of the other shards. Sharding can be used in scenarios like scalability, availability, and geo-distribution. Sharding can be implemented using several different algorithms such as range-based sharding, hash-based sharding, and directory-based sharding.
+ 
+Sharding splits a database horizontally, distributing rows of the same table across multiple database servers based on a shard key, such as user ID. Each shard holds a subset of the total data, which allows the system to scale beyond what a single server could handle. Choosing a good shard key is critical, since a poor choice can lead to uneven load across shards.

 Visit the following resources to learn more:

- [@article@Sharding pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/sharding)
- [@feed@Explore top posts about Backend Development](https://app.daily.dev/tags/backend?ref=roadmapsh)
+- [@article@Sharding pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/sharding)
@@ -1,10 +1,7 @@
 # Sidecar
-
-Deploy components of an application into a separate process or container to provide isolation and encapsulation. This pattern can also enable applications to be composed of heterogeneous components and technologies.
-
-This pattern is named Sidecar because it resembles a sidecar attached to a motorcycle. In the pattern, the sidecar is attached to a parent application and provides supporting features for the application. The sidecar also shares the same lifecycle as the parent application, being created and retired alongside the parent. The sidecar pattern is sometimes referred to as the sidekick pattern and is a decomposition pattern.
+ 
+The sidecar pattern deploys supporting components, like logging, monitoring, or networking logic, as a separate process alongside the main application, rather than building that logic directly into the application code. This lets shared infrastructure concerns be updated and reused independently of the application itself. Service meshes commonly use sidecars to handle networking between microservices.

 Visit the following resources to learn more:

- [@article@Sidecar pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar)
- [@feed@Explore top posts about Infrastructure](https://app.daily.dev/tags/infrastructure?ref=roadmapsh)
+- [@article@Sidecar pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar)
@@ -1,14 +1,8 @@
 # SQL Tuning
-
-SQL tuning is the attempt to diagnose and repair SQL statements that fail to meet a performance standard. It is a broad topic and many books have been written as reference. It's important to benchmark and profile to simulate and uncover bottlenecks.
-
-*   Benchmark - Simulate high-load situations with tools such as ab.
-*   Profile - Enable tools such as the slow query log to help track performance issues.
-
-Benchmarking and profiling might point you to the following optimizations.
+ 
+SQL tuning is the process of optimizing database queries and schema design to improve performance. It includes techniques like adding appropriate indexes, rewriting slow queries, avoiding unnecessary joins, and analyzing query execution plans to find bottlenecks. Well-tuned queries reduce load on the database and improve response times for the whole application.

 Visit the following resources to learn more:

 - [@official@Introduction to SQL Tuning - Oracle](https://docs.oracle.com/en/database/oracle/oracle-database/23/tgsql/introduction-to-sql-tuning.html#GUID-B653E5F3-F078-4BBC-9516-B892960046A2)
- [@article@Query Optimization for Mere Humans in PostgreSQL](https://towardsdatascience.com/query-optimization-for-mere-humans-in-postgresql-875ab864390a/)
- [@feed@Explore top posts about SQL](https://app.daily.dev/tags/sql?ref=roadmapsh)
+- [@article@Query Optimization for Mere Humans in PostgreSQL](https://towardsdatascience.com/query-optimization-for-mere-humans-in-postgresql-875ab864390a/)
@@ -1,14 +1,10 @@
-# SQL vs noSQL
-
-SQL databases, such as MySQL and PostgreSQL, are best suited for structured, relational data and use a fixed schema. They provide robust ACID (Atomicity, Consistency, Isolation, Durability) transactions and support complex queries and joins.
-
-NoSQL databases, such as MongoDB and Cassandra, are best suited for unstructured, non-relational data and use a flexible schema. They provide high scalability and performance for large amounts of data and are often used in big data and real-time web applications.
-
-The choice between SQL and NoSQL depends on the specific use case and requirements of the project. If you need to store and query structured data with complex relationships, an SQL database is likely a better choice. If you need to store and query large amounts of unstructured data with high scalability and performance, a NoSQL database may be a better choice.
+# SQL vs NoSQL
+ 
+SQL databases store data in structured tables with predefined schemas and relationships, and they support complex queries through SQL. NoSQL databases store data in more flexible formats, such as key-value pairs, documents, or graphs, and generally trade strict consistency and rigid schemas for better horizontal scalability. The choice between them depends on the data structure, consistency needs, and expected scale of the application.

 Visit the following resources to learn more:

+- [@article@Types of NoSQL Databases: How to Choose the Right One](https://roadmap.sh/backend/types-of-nosql-databases)
 - [@article@SQL vs NoSQL: The Differences](https://www.sitepoint.com/sql-vs-nosql-differences/)
 - [@article@SQL vs. NoSQL Databases: What’s the Difference?](https://www.ibm.com/blog/sql-vs-nosql/)
- [@article@NoSQL vs. SQL Databases](https://www.mongodb.com/nosql-explained/nosql-vs-sql)
- [@feed@Explore top posts about NoSQL](https://app.daily.dev/tags/nosql?ref=roadmapsh)
+- [@article@NoSQL vs. SQL Databases](https://www.mongodb.com/nosql-explained/nosql-vs-sql)
@@ -1,6 +1,6 @@
 # Static Content Hosting
-
-Deploy static content to a cloud-based storage service that can deliver them directly to the client. This can reduce the need for potentially expensive compute instances.
+ 
+Static content hosting serves fixed assets, such as images, stylesheets, and scripts, directly from a storage service or CDN instead of through the application server. Since this content does not change per request, serving it separately reduces load on the application and takes advantage of caching and edge distribution. It is a common way to speed up delivery of non-dynamic parts of a website.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # Static Content Hosting

-Deploy static content to a cloud-based storage service that can deliver them directly to the client. This can reduce the need for potentially expensive compute instances.
+Static content hosting involves storing fixed files—such as HTML documents, CSS stylesheets, JavaScript files, and images—on a cloud-based storage service rather than serving them directly from a traditional application server. By offloading these files to a distributed storage system, you can serve them to users through a Content Delivery Network (CDN), which caches the data at various geographic locations to reduce latency and decrease the processing load on your primary backend infrastructure.

 Visit the following resources to learn more:

@@ -1,22 +1,6 @@
 # Synchronous I/O
-
-Blocking the calling thread while I/O completes can reduce performance and affect vertical scalability.
-
-A synchronous I/O operation blocks the calling thread while the I/O completes. The calling thread enters a wait state and is unable to perform useful work during this interval, wasting processing resources.
-
-Common examples of I/O include:
-
-*   Retrieving or persisting data to a database or any type of persistent storage.
-*   Sending a request to a web service.
-*   Posting a message or retrieving a message from a queue.
-*   Writing to or reading from a local file.
-
-This antipattern typically occurs because:
-
-*   It appears to be the most intuitive way to perform an operation.
-*   The application requires a response from a request.
-*   The application uses a library that only provides synchronous methods for I/O.
-*   An external library performs synchronous I/O operations internally. A single synchronous I/O call can block an entire call chain.
+ 
+Synchronous I/O blocks the calling thread until an input or output operation, like a network call or disk read, completes. Under high load, this ties up threads waiting on slow operations instead of doing useful work, which limits how many concurrent requests a system can handle. Switching to asynchronous I/O lets a thread continue other work while waiting for the operation to finish.

 Visit the following resources to learn more:

@@ -1,8 +1,6 @@
 # Task Queues
-
-Tasks queues receive tasks and their related data, runs them, then delivers their results. They can support scheduling and can be used to run computationally-intensive jobs in the background.
-
-[Celery](https://docs.celeryproject.org/en/stable/) has support for scheduling and primarily has python support.
+ 
+A task queue holds units of work, called tasks, that are processed asynchronously by one or more worker processes. Producers add tasks to the queue, and workers pull tasks off and execute them independently of the request that created them. This decouples slow or resource-intensive work from the main application flow.

 Visit the following resources to learn more:

@@ -1,14 +1,10 @@
 # TCP
-
-TCP (Transmission Control Protocol) is a connection-oriented, reliable, and ordered protocol used for transmitting data over an IP network. It establishes a connection between a sender and receiver before data transfer begins, ensures that data packets arrive in the correct sequence without errors, and provides mechanisms for retransmission of lost packets and flow control to manage network congestion.
+ 
+TCP, or Transmission Control Protocol, is a connection-oriented protocol that guarantees reliable, ordered delivery of data between two systems. It establishes a connection before sending data and manages retransmission of lost packets and flow control. Applications that need guaranteed delivery, like file transfers or web traffic, typically rely on TCP.

 Visit the following resources to learn more:

 - [@opensource@What Is TCP?](https://github.com/donnemartin/system-design-primer#transmission-control-protocol-tcp)
 - [@article@What is the difference between HTTP protocol and TCP protocol?](https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol)
 - [@article@Networking for game programming](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/)
- [@article@Key differences between TCP and UDP protocols](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/)
- [@article@Difference between TCP and UDP](http://stackoverflow.com/questions/5970383/difference-between-tcp-and-udp)
- [@article@Transmission control protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
- [@article@User datagram protocol](https://en.wikipedia.org/wiki/User_Datagram_Protocol)
- [@article@Scaling memcache at Facebook](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf)
+- [@article@Key differences between TCP and UDP protocols](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/)
@@ -1,22 +1,9 @@
 # UDP
-
-UDP is connectionless. Datagrams (analogous to packets) are guaranteed only at the datagram level. Datagrams might reach their destination out of order or not at all. UDP does not support congestion control. Without the guarantees that TCP support, UDP is generally more efficient.
-
-UDP can broadcast, sending datagrams to all devices on the subnet. This is useful with DHCP because the client has not yet received an IP address, thus preventing a way for TCP to stream without the IP address.
-
-UDP is less reliable but works well in real time use cases such as VoIP, video chat, streaming, and realtime multiplayer games.
-
-Use UDP over TCP when:
-
-*   You need the lowest latency
-*   Late data is worse than loss of data
-*   You want to implement your own error correction
+ 
+UDP, or User Datagram Protocol, is a connectionless protocol that sends data without guaranteeing delivery, order, or error checking. This makes it faster and lighter than TCP, at the cost of reliability. It suits use cases where speed matters more than perfect delivery, such as video streaming or online gaming.

 Visit the following resources to learn more:

 - [@article@Networking for game programming](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/)
 - [@article@Key differences between TCP and UDP protocols](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/)
- [@article@Difference between TCP and UDP](http://stackoverflow.com/questions/5970383/difference-between-tcp-and-udp)
- [@article@Transmission control protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
- [@article@User datagram protocol](https://en.wikipedia.org/wiki/User_Datagram_Protocol)
- [@article@Scaling memcache at Facebook](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf)
+- [@article@Difference between TCP and UDP](http://stackoverflow.com/questions/5970383/difference-between-tcp-and-udp)
@@ -1,14 +1,7 @@
 # Usage Monitoring
-
-Usage monitoring tracks how the features and components of an application are used. An operator can use the gathered data to:
-
-*   Determine which features are heavily used and determine any potential hotspots in the system. High-traffic elements might benefit from functional partitioning or even replication to spread the load more evenly. An operator can also use this information to ascertain which features are infrequently used and are possible candidates for retirement or replacement in a future version of the system.
-*   Obtain information about the operational events of the system under normal use. For example, in an e-commerce site, you can record the statistical information about the number of transactions and the volume of customers that are responsible for them. This information can be used for capacity planning as the number of customers grows.
-*   Detect (possibly indirectly) user satisfaction with the performance or functionality of the system. For example, if a large number of customers in an e-commerce system regularly abandon their shopping carts, this might be due to a problem with the checkout functionality.
-*   Generate billing information. A commercial application or multitenant service might charge customers for the resources that they use.
-*   Enforce quotas. If a user in a multitenant system exceeds their paid quota of processing time or resource usage during a specified period, their access can be limited or processing can be throttled.
+ 
+Usage monitoring tracks how a system's resources and features are being used, such as request volume, active users, or feature adoption. This data helps with capacity planning and understanding which parts of a system need more investment. It is also useful for billing in systems with usage-based pricing.

 Visit the following resources to learn more:

- [@article@Usage Monitoring](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring#usage-monitoring)
- [@feed@Explore top posts about Monitoring](https://app.daily.dev/tags/monitoring?ref=roadmapsh)
+- [@article@Usage Monitoring](https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring#usage-monitoring)
@@ -1,6 +1,6 @@
 # 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.
+ 
+The valet key pattern grants a client temporary, limited access directly to a specific resource, like a file in cloud storage, without routing all the data through the application server. This reduces load on the application and improves performance for large data transfers. Access is scoped narrowly and expires after a set time, limiting the risk if the key is exposed.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
-# Visualization and Alerts
-
-An important aspect of any monitoring system is the ability to present the data in such a way that an operator can quickly spot any trends or problems. Also important is the ability to quickly inform an operator if a significant event has occurred that might require attention.
+# Visualization & Alerts
+ 
+Visualization and alerts turn raw monitoring data into dashboards and notifications that people can act on. Dashboards give a real-time or historical view of system health, while alerts notify the right people automatically when a metric crosses a concerning threshold. Together they close the loop between collecting data and actually responding to problems.

 Visit the following resources to learn more:

--- a/Show More
+++ b/Show More