Adding content to 102-design-and-implementation

content/system-design
syedmouaazfarrukh 2 years ago
parent daa5c7288c
commit 17063f5e7f
  1. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/100-ambassador.md
  2. 8
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/101-anti-corruption-layer.md
  3. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/102-backends-for-frontend.md
  4. 10
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/103-cqrs.md
  5. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/104-compute-resource-consolidation.md
  6. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/105-external-configuration-store.md
  7. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/106-gateway-aggregation.md
  8. 8
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/107-gateway-offloading.md
  9. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/108-gateway-routing.md
  10. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/109-leader-election.md
  11. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/110-pipes-and-filters.md
  12. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/111-sidecar.md
  13. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/112-static-content-hosting.md
  14. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/113-strangler-fig.md
  15. 9
      src/roadmaps/system-design/content/118-cloud-design-patterns/102-design-and-implementation/index.md

@ -1 +1,8 @@
# Ambassador
# Ambassador
Ambassador in system design is a type of software that acts as a facade for other services or applications. It's a reverse proxy and service mesh that allows to control access to services, and provide features such as authentication, rate limiting, and observability. Ambassador can be used to route requests, authenticate and authorize requests, provide observability, and rate limiting. Ambassador is designed to work with Kubernetes and other cloud-native platforms.
To learn more, visit the following links:
- [Design System Ambassadors](https://medium.com/sprout-social-design/design-system-ambassadors-c240e480baf6)
- [Ambassador pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/ambassador)

@ -1 +1,7 @@
# Anti corruption layer
# Anti-orruption Layer
An Anti-Corruption Layer (ACL) in system design is a software pattern that acts as a buffer between a system and external systems or legacy systems that use incompatible data formats or protocols. It's purpose is to protect the internal system from being affected by changes or inconsistencies in the external systems, and to provide a stable and consistent interface for the internal system to interact with the external systems. It can be used in scenarios like integration with legacy systems, integration with external systems, and isolation of dependencies. An ACL can be implemented using several different techniques such as data mapping, data validation, and error handling.
To learn more, visit the following links:
- [Anti-corruption Layer pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer)

@ -1 +1,8 @@
# Backends for frontend
# Backends for Frontend
Backends for Frontend (BFF) in system design is a pattern that involves creating a separate backend service for each frontend client. This allows each client to have its own API, tailored to its specific needs, while still sharing a common set of underlying services and data. BFF can be used to provide a tailored API, decouple frontend and backend, and reduce complexity. BFF can be implemented using several different techniques such as Microservices and API Gateway.
To learn more, visit the following links:
- [Why “Backend For Frontend” Application Architecture?](https://www.mobilelive.ca/blog/why-backend-for-frontend-application-architecture)
- [what is Backend for frontend (BFF) pattern](https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0)

@ -1 +1,9 @@
# Cqrs
# CQRS
CQRS (Command Query Responsibility Segregation) in system design is a pattern that separates the responsibilities of handling read and write operations in a system. This pattern allows for the separation of concerns between the read and write operations, and can be used to improve the scalability, performance, and maintainability of a system.
In this pattern, the read and write operations are handled by different components in the system. The write operations, known as commands, are handled by a Command component that updates the state of the system. The read operations, known as queries, are handled by a Query component that retrieves the current state of the system.
Learn more from the following links:
- [CQRS pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs)

@ -1 +1,8 @@
# Compute resource consolidation
# Compute Resource Consolidation
Compute resource consolidation in system design is the process of combining multiple servers, storage devices, and network resources into a smaller number of more powerful and efficient systems. This approach can be used to reduce costs, improve performance, and simplify the management and maintenance of the IT infrastructure. Compute resource consolidation can be achieved through several different techniques such as Virtualization, Cloud computing, and Containers. It can also be used to reduce costs, improve performance, and simplify management and maintenance.
To learn more, visit the following links:
- [Compute Resource Consolidation pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/compute-resource-consolidation)
- [Tutorial - The Compute Resource Consolidation Pattern](https://www.youtube.com/watch?v=XzBmJvu6gpQ)

@ -1 +1,8 @@
# External configuration store
# External Configuration Store
An External Configuration Store (ECS) in system design is a centralized, external location where system configuration settings are stored and managed. It separates the configuration of a system from the code of the system, making it easier to manage and update the configuration settings. It can be used in scenarios such as centralized configuration management, dynamic configuration and environment-specific configuration. It can be implemented using techniques such as environment variables, configuration files, and distributed key-value stores.
To learn more, visit the following links:
- [External Configuration Store pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/external-configuration-store)
- [External Configuration Store Pattern - Azure Cloud Design Patterns](https://www.youtube.com/watch?v=e-x1G4fRzf8)

@ -1 +1,8 @@
# Gateway aggregation
# Gateway Aggregation
Gateway Aggregation in system design is a pattern that involves using a single gateway to aggregate multiple services or microservices into a single endpoint. This allows for a simplified client-side API and can also provide additional functionality such as authentication, rate limiting, and observability. It can be used to simplify the client-side API, provide additional functionality, and decouple the client and services. It can be implemented using techniques such as API Gateway and Service Mesh.
To learn more, visit the following links:
- [Gateway Aggregation pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation)
- [Overview of Gateway Aggregation Pattern](https://medium.com/design-microservices-architecture-with-patterns/gateway-aggregation-pattern-9ff92e1771d0)

@ -1 +1,7 @@
# Gateway offloading
# Gateway Offloading
Gateway Offloading in system design is a pattern that involves using a gateway to offload certain tasks or processing from the backend services or microservices to the gateway itself. This can be used to reduce the load on the backend services, improve performance, and provide additional functionality such as caching, compression, and encryption. It can be implemented using techniques such as API Gateway and Edge Computing.
To learn more, visit the following links:
- [Gateway Offloading pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-offloading)

@ -1 +1,8 @@
# Gateway routing
# Gateway Routing
Gateway Routing in system design is a pattern that involves using a gateway to route requests to the appropriate backend service or microservice. The gateway acts as a single entry point for all incoming requests and routes them to the correct service based on the request's information such as the endpoint, headers, or payload. It can be used to decouple the client and services, provide additional functionality, and scale the system. It can be implemented using techniques such as API Gateway and Service Mesh.
To learn more, visit the following links:
- [Gateway Routing pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-routing)
- [Iverview of Gateway Routing Pattern](https://medium.com/design-microservices-architecture-with-patterns/gateway-routing-pattern-f40eb56a2dd9)

@ -1 +1,8 @@
# Leader election
# Leader Election
Leader Election in system design is a pattern that is used to elect a leader among a group of distributed nodes in a system. The leader is responsible for coordinating the activities of the other nodes and making decisions on behalf of the group. Leader Election is important in distributed systems, as it ensures that there is a single point of coordination and decision-making, reducing the risk of conflicting actions or duplicate work. Leader Election can be used to ensure a single point of coordination, provide fault tolerance, and scalability. There are several algorithms such as Raft, Paxos, and Zab that can be used to implement Leader Election in distributed systems.
To learn more, visit the following links:
- [Overview of Leader Election](https://aws.amazon.com/builders-library/leader-election-in-distributed-systems/)
- [What is Leader Election in system design?](https://www.enjoyalgorithms.com/blog/leader-election-system-design)

@ -1 +1,8 @@
# Pipes and filters
# Pipes and Filters
Pipes and Filters in system design is a pattern that is used to decompose a large system into smaller, reusable components that can be combined in different ways to perform different tasks. It is based on the idea of data flowing through a series of connected "pipes", where each "pipe" represents a processing step or "filter" that performs a specific task on the data. It can be used to decompose a large system, increase flexibility and increase reusability. It can be implemented in several ways such as pipeline and Chain of Responsibility pattern.
To learn more, visit the following links:
- [Pipe and Filter Architectural Style](https://cs.uwaterloo.ca/~m2nagapp/courses/CS446/1181/Arch_Design_Activity/PipeFilter.pdf)
- [What are Pipes and Filters?](https://syedhasan010.medium.com/pipe-and-filter-architecture-bd7babdb908)

@ -1 +1,8 @@
# Sidecar
# Sidecar
A Sidecar in system design is a pattern that involves running an additional process alongside a primary process, in order to provide additional functionality to the primary process. The sidecar process is typically used to manage cross-cutting concerns such as logging, monitoring, security, or networking. It is used to provide additional functionality, decouple the primary process from the additional functionality, and allow for easier upgrades. It can be implemented in several ways such as Service Mesh and Sidecar Container.
To learn more, visit the following links:
- [Sidecar pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar)
- [What is Sidecar Pattern?](https://www.oreilly.com/library/view/designing-distributed-systems/9781491983638/ch02.html)

@ -1 +1,8 @@
# Static content hosting
# Static Content Hosting
Static Content Hosting in system design is a technique used to serve static resources such as images, stylesheets, and JavaScript files, from a dedicated server or service, rather than from the main application server. This approach can be used to improve the performance, scalability, and availability of a system. Static content hosting can be used in scenarios like performance, scalability, and availability. Static content hosting can be implemented using several different techniques such as Content Delivery Network (CDN), Object Storage and File Server.
Learn more from the following links:
- [The pros and cons of the Static Content Hosting](https://www.redhat.com/architect/pros-and-cons-static-content-hosting-architecture-pattern)
- [Static Content Hosting pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/static-content-hosting)

@ -1 +1,8 @@
# Strangler fig
# Strangler fig
Strangler Fig in system design is a pattern that is used to gradually replace a monolithic application with a microservices-based architecture. It's based on the idea of a "strangler fig" vine slowly wrapping around and strangling a tree, gradually replacing it. This pattern can be used to gradually replace a monolithic application, reduce the impact of changes, and preserve existing functionality. It can be implemented in several ways such as API Gateway and Service Mesh.
To learn more, visit the following links:
- [The Sstrangler fig pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-aspnet-web-services/fig-pattern.html)
- [What is Strangler fig?](https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig)

@ -1 +1,8 @@
# Design and implementation
# Design and Implementation
Design and Implementation in system design refers to the process of creating a system that meets the requirements and goals of the stakeholders. It involves several steps such as requirements gathering, design, implementation, testing, deployment, and maintenance. The design phase involves creating a high-level plan for the system, including the overall architecture, the components that will be used, and the interfaces between them. The implementation phase involves taking the design and creating a working system using the chosen technologies and tools.
To learn more, visit the following links:
- [What is Design and Implementation?](https://www.marketlinks.org/good-practice-center/value-chain-wiki/design-and-implementation-overview)
- [Overview of System Design and Implementation](https://www.tutorialspoint.com/operating-system-design-and-implementation)
Loading…
Cancel
Save