mirror of
https://github.com/github/awesome-copilot.git
synced 2026-03-13 12:45:13 +00:00
* Fatih: Add Cloud Design Patterns instructions for distributed systems architecture * Convert Cloud Design Patterns from instruction to skill * Update skills/cloud-design-patterns/SKILL.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update skills/cloud-design-patterns/references/reliability-resilience.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
128 lines
4.6 KiB
Markdown
128 lines
4.6 KiB
Markdown
# Architecture & Design Patterns
|
|
|
|
## Anti-Corruption Layer Pattern
|
|
|
|
**Problem**: New systems must integrate with legacy systems that use outdated models or technologies.
|
|
|
|
**Solution**: Implement a façade or adapter layer between a modern application and a legacy system to prevent legacy constraints from affecting new design.
|
|
|
|
**When to Use**:
|
|
- Migrating from legacy systems incrementally
|
|
- Integrating with third-party systems with different domain models
|
|
- Protecting modern architectures from legacy constraints
|
|
|
|
**Implementation Considerations**:
|
|
- Create translation layer between domain models
|
|
- Map between legacy and modern data structures
|
|
- Isolate legacy system interfaces behind abstractions
|
|
- Consider performance impact of translation
|
|
- Plan for eventual removal if migration is complete
|
|
|
|
## Backends for Frontends (BFF) Pattern
|
|
|
|
**Problem**: A single backend may not optimally serve different client types.
|
|
|
|
**Solution**: Create separate backend services to serve specific frontend applications or interfaces.
|
|
|
|
**When to Use**:
|
|
- Different client types (web, mobile, IoT) have different needs
|
|
- Optimizing payload size and shape per client
|
|
- Reducing coupling between frontend and shared backend
|
|
|
|
**Implementation Considerations**:
|
|
- Create one BFF per user experience or client type
|
|
- Tailor API contracts to frontend needs
|
|
- Avoid duplicating business logic across BFFs
|
|
- Share common services between BFFs
|
|
- Manage increased number of services
|
|
|
|
## Gateway Aggregation Pattern
|
|
|
|
**Problem**: Clients need data from multiple backend services.
|
|
|
|
**Solution**: Use a gateway to aggregate multiple individual requests into a single request.
|
|
|
|
**When to Use**:
|
|
- Reducing chattiness between clients and backends
|
|
- Combining data from multiple sources for a single view
|
|
- Reducing latency by parallelizing backend calls
|
|
|
|
**Implementation Considerations**:
|
|
- API gateway aggregates responses from multiple services
|
|
- Execute backend calls in parallel where possible
|
|
- Handle partial failures appropriately
|
|
- Consider caching of aggregated responses
|
|
- Avoid creating a monolithic gateway
|
|
|
|
## Gateway Offloading Pattern
|
|
|
|
**Problem**: Shared functionality is duplicated across multiple services.
|
|
|
|
**Solution**: Offload shared or specialized service functionality to a gateway proxy.
|
|
|
|
**When to Use**:
|
|
- Centralizing cross-cutting concerns (SSL, authentication, logging)
|
|
- Simplifying service implementation
|
|
- Standardizing shared functionality
|
|
|
|
**Implementation Considerations**:
|
|
- Offload SSL termination to gateway
|
|
- Implement authentication and authorization at gateway
|
|
- Handle rate limiting and throttling
|
|
- Provide request/response logging
|
|
- Avoid making gateway a bottleneck
|
|
|
|
## Gateway Routing Pattern
|
|
|
|
**Problem**: Clients need to access multiple services through a single endpoint.
|
|
|
|
**Solution**: Route requests to multiple services using a single endpoint.
|
|
|
|
**When to Use**:
|
|
- Providing a single entry point for multiple services
|
|
- Abstracting backend service topology from clients
|
|
- Enabling service versioning and migration strategies
|
|
|
|
**Implementation Considerations**:
|
|
- Route based on URL path, headers, or query parameters
|
|
- Support URL rewriting and transformation
|
|
- Enable A/B testing and canary deployments
|
|
- Implement health checks for backend services
|
|
- Monitor routing performance
|
|
|
|
## Sidecar Pattern
|
|
|
|
**Problem**: Applications need auxiliary functionality without coupling.
|
|
|
|
**Solution**: Deploy components of an application into a separate process or container to provide isolation and encapsulation.
|
|
|
|
**When to Use**:
|
|
- Adding functionality to applications without modifying them
|
|
- Implementing cross-cutting concerns (logging, monitoring, security)
|
|
- Supporting heterogeneous environments
|
|
|
|
**Implementation Considerations**:
|
|
- Deploy sidecar alongside main application
|
|
- Share lifecycle, resources, and network with main application
|
|
- Use for proxying, logging, configuration, or monitoring
|
|
- Consider resource overhead of additional containers
|
|
- Standardize sidecar implementations across services
|
|
|
|
## Strangler Fig Pattern
|
|
|
|
**Problem**: Legacy systems are risky to replace all at once.
|
|
|
|
**Solution**: Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services.
|
|
|
|
**When to Use**:
|
|
- Modernizing legacy applications
|
|
- Reducing risk of big-bang migrations
|
|
- Enabling incremental business value delivery
|
|
|
|
**Implementation Considerations**:
|
|
- Identify functionality to migrate incrementally
|
|
- Use facade or proxy to route between old and new
|
|
- Migrate less risky components first
|
|
- Run old and new systems in parallel initially
|
|
- Plan for eventual decommissioning of legacy system
|