Cloud Design Patterns - amitbhilagude/userfullinks GitHub Wiki

Categories
1. Data Management
2. Design and Implementations
3. Messaging
Ambassador Pattern
1. Helper Service on-behalf of application to send request
2. Commonly used for Used monitoring, routing, logging, security
3. It Works as a Proxy. There could be a scenario that we have a legacy application that doesn't want to upgrade it but the requirement to interact with remote service. In that case, a new application can be built to interact with remote service which can be hosted in the same environment as legacy applications, and legacy applications can interact with requests and responses.
4. Scenarios
  1. Multiple applications running in the same host requires common functionalities like Logging, Routing to individual applications or Circuit breaker pattern.
  2. Legacy application doesn't support a lot of change and having an ambassador pattern can take care of this.
  3. New team doesn't want to break anything on the Legacy Application but they can extend the functionality.
  4. Disadvantage
    1. Network latency
    2. Need to have a highly scalable proxy as requests will route through this and we don't want any bottleneck.
Anti-corruption Layer systems
1. Anti-corruption layer is like introducing an Adapter or facade pattern in two systems.
2. Scenario
  1. One system is built in the latest technology stack and Another system is a legacy system and both need to communicate.
  2. Communications between the system are not the same way and you need a layer that can translate the request with the appropriate form before forwarding this to the Another system.
3. Challenges
  1. Introducing the Anti-corruption layer needs to consider high availability and maintainability.
  2. Need to find out is it going to be permanent solution assuming the Legacy system will go away in the future.
Asynchronous Request and response pattern
1. Client application sends an asynchronous request to the backend service and the backend service will give you a response back when it is ready.
2. Commonly used for a web application where the front application call APIs and gets the response of 202 accepted status and wait does the polling for status APIs.
3. This pattern is also uses messaging pattern where the client Application sends messages and wait to get the confirmation with the status endpoint. This is managed by Polling or a Two-way communication approach like Signal R.
4. Scenario:
  1. Panda command and polling
  2. Azure Resource Provisioning follows a similar pattern.
5. Issues and consideration
  1. API will return 202 accepted the response and get the location URL back for polling.
  2. Polling retry needs to be considered well else the status endpoint will become chatty.
  3. Polling status endpoint should return correct response e.g. 200 OK, 201 created or 204 Not content or 4xx for error content.
Backends for the front ends pattern
1. Create separate backend services which are consumed by any front end application
2. Backend service is consumed by Mobile or Web applications.
3. Scenarios:
  1. Require web application and Mobile native app both need to have backend service requirement. Either create dedicated service per app or have a common service. The decision will be based on interfaces required to consume this e.g. Mobile may need to have different endpoints with low data
4. Issues and considerations
  1. Two different services will create duplications and additional maintainability.
  2. Decisions should be based on Teams, Interfaces required etc
Bulkhead Pattern
1. Isolate the services so that one service will fail, it will not impact the other services.
2. Scenarios:
  1. Creating Microservice or having Pods in Kubernetes each pod will have own CPU and memory and it will not impact other Pods.
  2. Services will have a dedicated connection pool for DBs.
3. Issues and considerations
  1. Additional overhead of managing additional resources like connection pool for DB however it is a good option for Kubernetes.
Cache-Aside Pattern
1. Load data on-demand on cache from the data store.
2. Scenarios
  1. Introducing Redis cache to avoid roundtrip with DB
3. Issues and considerations
  1. Data consistency. How to do make sure data in the cache is consistent in DB and cache.
  2. MAS scenario in a project where a change in role doesn't reflect.
SAGA Pattern
1. It is implemented using two types of Microservices
  1. Choreography
  2. Orchestrator
2. Choreography Pattern
  1. This pattern raises event-based architecture. All Microservices communicated to each other using events raised in Messaging system like Service Bus.
3. Orchestrator Pattern
  1. Single orchestrator service takes care of communicating to Microservices. Microservices raises command to Orchestrator service which communicates other Microservices.
Circuit Breaker Pattern
1. This pattern will make sure your system is highly available.
2. One of the endpoints is not available for a specific time e.g. CPU usage is higher to a specific node in Microservice then the request can route to another node.
3. This pattern also follows the retry pattern and health endpoint monitoring pattern.
4. Scenarios
  1. Reverse proxy like nginx or traefik or Load balancer will use circuit breaker pattern so that it will check if API is available to serve the request and it can retry it n number time after a specific duration. It can check the CPU usage node is high by using a health endpoint monitoring pattern.
Claim check pattern
1. Send big-size messages e.g. File into messaging architecture like service bus which has limitations to sending messages.
2. Service bus: 256 kB - 1 MB, Event grid - 64 KB, Event Hub 256 KB- 1 MB.
3. Split the message this is one option or if it is binary file upload it into storage and send the URL of storage as a claim.
4. Issues and considerations
  1. Additional storage
  2. Need to delete file from storage to grow it more
Compensating transaction Pattern
1. This pattern is used to keep the consistency in multiple databases by creating event to another DB when one DB is updated.
2. This pattern is not preferable as this will become more complex when you will have a rollback when any one DB update is failed.
3. Design system to avoid such pattern.
4. Issues and considerations
  1. Need to maintain original state which can be used to update for rollback scenario.
  2. Concurrency needs to be considered here if the same record gets updated by another transaction. Keep short term lock until transaction is updated in multiple databases.
Deployment Stamp Pattern
1. Deployment stamp pattern is creating a single app with a dedicated database multitenant pattern.
2. You may have a scenario to create a separate instance of each app in each region. Where a set of App deployed in each region is called Stamp.
3. This is a good option to avoid latency for customers located in multiple regions.
4. Issues and considerations
  1. Having additional instances will have more overhead.
  2. Deployment of this instance needs to be automated with ARM templates or biceps
CQRS Pattern (Command and Query Responsibility Segregation Pattern)
1. This pattern is used to have different models created to perform read and write operations for many reasons e.g. Security, performance etc.
2. e.g. This is used for Panda where you raise command to write into AAA but Read through Graph API.
3. Common approach for this is written operations are done using command and read can directly get approach.
4. Scenario:
  1. You may have a lot of reads and few writes and option scale read API based on load
  2. You have to write operations to do on-behalf so that you can do raise the command for writing it.
  3. Separating and DTOs models for reading and writing.
5. Issues and considerations
  1. Multiple models for a single ORM tool.
  2. Need to make sure new properties are updated in both places.
Competing Consumers Pattern
1. This pattern is used to manage the concurrent requests and to avoid a single receiver which may create a bottleneck in pick load.
2. This pattern is similar to the load balancer in front of Microservices in scenarios like AKS but it is good for Event-driven and monolith architecture
3. You can have a service bus instead of the load balancer and install multiple receivers so that anyone will pick that message.
Edge Workload Configurations Pattern
1. This pattern is used to manage the configuration at edge locations assuming you will have multiple edge locations and it is hard to manage the consistency in the configurations.
2. In this scenario, All configurations are maintained cloud and deployed using CI-CD pipelines.
3. It will have an auditing mechanism that is stored at the edge locations.
Eventing Source pattern
1. This pattern is used to avoid the concurrency for a single record.
2. Scenario
  1. e-commerce ticket booking system has a ticket availability count stored in DB as it needs to be incremented or decremented based on Tickets booked or canceled. Challenge with this when there is massive request on last day of booking there would be issue to update the record. Solution for this creates an immutable event for every action and stores that as a single record in eventing store e.g. Record with booking canceled and Record with Booking done. To show the ticket available count actual query will be done on the event then do the aggregation to show the count. In this way, we are avoiding a single record to be updated.
3. Issues and considerations
  1. May cause delays in the time event published and queried before that.
  2. Massive events that get created and generated may have challenges to aggregate them. create a snapshot for a specific time range and replay another event with the latest information e.g seat availability that will request aggregations.
External Configuration Pattern
1. This pattern is used to store the configuration in the external store so that the application picks this runtime.
2. Scenario
  1. Multiple applications using one common service URL and maintain as part of app settings. Changing this URL needs to redeploy all apps. use of Azure offerings like Azure App Configuration which supports key-value pair or external storage like Blob.
Federated Identity Pattern
1. Delegate authenticating mechanism to external identity Provider instead of Application responsibilities.
2. This will allow having SSO experience for multiple applications.
3. Issues and Considerations
  1. Single point of failure if it didn't scale well.
Gatekeeper Pattern
1. Host service in front of every service to sanitize requests before sending them back to the backend service.
2. This will act as a firewall.
3. Issues and consideration
  1. Needs to be a highly available or scalable system.
Gateway aggregations
1. This pattern is used when you need to call multiple backend services and need to have aggregated responses to the client.
2. Introducing Gateway as another service that will take care of routing requests to the backend service and aggregate the result and send it back to the client.
3. Issues and considerations
  1. It needs to be highly scalable. Alternate options are the use of bulkhead pattern which will create multiple gateway aggregation services
  2. It needs to have a retry and timeout mechanism to make sure backend service is available
  3. Have the option to partial data in the response when one of the services is not available.
Gateway offloading
1. Common service which is going to common tasks like SSL certificate for the services.
2. Application gateway is one offering that can act as Gateway offloading as it does SSL offloading. If you using the PaaS offering then the certificate can be uploaded there and redirect requests to the app service. If any other service within vNet then SSL termination can be done here.
Gateway Routing Pattern
1. Use a gateway to route the request like Application gateway or nginx.
Geode Pattern
1. Geode(GEOgraphical noDE) pattern is geo-replication of service or DB to avoid latency
2. Cosmos DB, Having services in each region using Deployment stamp pattern.
Health endpoint Monitoring
1. Checking the service or database availability at regular intervals and retry it n-times of time before it reports that it is unavailable.
2. E.g. Application gateway and Load balancer use the health probes.
3. .Net middleware also supports /health endpoint which can be used for a health check.
4. Exposing end-point also need security consideration so that it is not public can be protected from attacks e.g. IP restrictions or security with Key etc.
Index Table Pattern
1. Create another index table for the secondary key if it is also frequently used.
2. It requires schema designed planned well to avoid duplication of record and make sure we follow DB normalisations.
Leader Election Pattern
1. Select a leader who will coordinate with all in-parallel tasks.
2. Scenario: Multiple services working in parallel and using shared resources e.g. DB or variables etc. The leader(new service) will make sure to coordinate and decide the priority.
Materialised view
1. Good option to improve the query performance.
2. Scenario: Require query from multiple Tables which can be created as Materialised view aggregates of all tables and required columns. The query will be executed against the view only.
3. MAS caching uses caching aside pattern which has data from AAA and cosmos.
4. Challange and considerations
  1. Need to update the view if any one of the tables get changed
  2. Expecting delay in data consistency between view and actual tables.
Priority Queue
1. Set the priority of the message so that it will enqueue first. By default, there is no offering Azure e.g. Service bus will guarantee that FIFO pattern, however, there are solutions to achieve this.
2. Service bus with Topics and subscriptions pattern. Message can have a custom filter with values like High and low. Subscription will have a filter based on this. This will filter messages and high priority messages will send to the appropriate subscription
3. Multiple service buses and high-priority messages can send to the specific service bus.
4. Use of data structure like Max heap where high priority message on top. It needs to have in-memory messages.
Publisher-subscriber Pattern.
Request-Reply pattern for messaging
Queue based load leveling pattern
1. Concurrent requests will en queue into a queue that has a single consumer.
2. It will act as a buffer to handle concurrency.