It is very important to consider all design patterns before designing any service, as it helps you build a predictable service that is secured, resilient, performant, scalable, available, and reliable with the following foundation pillars that gives maturity to your application. Traditionally, these patterns were not considered formally, but in the cloud era, we have much more flexibility to choose and consider these patterns during our design process, as these patterns are the building blocks for the cloud vendor service, and even they use the same pattern in designing their own infrastructure.
We are going to cover the following six design patterns. These topics are so broad that we can write a complete chapter on them, but we are going to give you a glimpse into these subtopics so that we can consider them while we are performing some practical implementation:
- Security
- Resiliency
- Performance
- Scalability
- Availability
- Reliability
The following diagram shows the design pattern pillar for new generation services:
All of the preceding topics are so important in distributed, multi-tenant, cloud-hosted environments, where you have to consider these patterns while designing your services. Some of the frequently used patterns under these topics are API throttling, Single Sign On (SSO) using federated authentication, rate limit, and sidecar container. Messaging, Management, and Monitoring are also the design patterns that are shown in the following mind map, but their subtopics are covered in our six pillars, as some show all of these overlaps:
The toolsets available on the market have all the functionality and configuration to practically implement them and take these design patterns in to a real, practical world. Very few organizations are aware of these topics, and those who have exposure to it have started building scalable massive applications and lead in their domain industry. AWS, Azure, and GCP are tried and tested, and they are leading the cloud market, whereas Netflix and YouTube are the top companies in the video streaming domain, and behind the scenes you will find that they have implemented these same design patterns while implementing their services.
Most of the cloud vendors release their well-architected framework, guidelines, and design patterns that they use to consult their customers and tell them to build their services. For example, Amazon has released the well-architected framework (WAF). The five pillars that are used during any design discussion whenever you will be building your services around AWS cloud are as follows:
-
Security
-
Reliability
-
Performance Efficiency
-
Cost Optimization
-
Operational Excellence
Mind maps are very useful for showing the relationship among these patterns so that you can get a good glimpse in a single view, and we tried to put them all together in the following design map. The following 32 are the broadly classified design patterns by Microsoft that you will find categorized under the previous seven design patterns. The next page shows a mind map of the design pattern:
The following are some brief descriptions about these design patterns:
|
Design pattern |
Summary |
|
Ambassador |
Helper service that sends network requests on behalf of consumer services or agents. |
|
Anti-corruption layer |
It helps you create a layer between a traditional legacy application and a newly designed application. |
|
Backends for frontends |
It helps give you an idea about how to create backend services that will be directly consumed by frontend services or UI. |
|
Bulkhead |
This gives an idea about how to isolate your application into pools so that one service failure doesn't impact the other service. |
|
Cache-aside |
Keeping data ready in the cache for fast access. |
|
Circuit breaker |
It helps you to design your service to handle failures where a service fix requires some time, and using a circuit breaker, you can implement logic about how you can delay or handle agent requests gracefully. |
|
CQRS |
Command and query responsibility segregation (CQRS) is a pattern that defines segregation operations to read data by using separate interfaces. |
|
Compensating transaction |
There are many conditions where your logic fails in the middle during execution, and you should implement functionality to gracefully roll back transactions to their original state. |
|
Competing consumers |
Enables multiple concurrent consumers to process messages received on the same messaging channel. |
|
Compute resource consolidation |
Consolidates multiple tasks or operations into a single computational unit. |
|
Event sourcing |
Uses an append-only store to record the full series of events that describe actions taken on data in a domain. |
|
External configuration store |
Moves configuration information out of the application deployment package to a centralized location. |
|
Federated identity |
Delegates authentication to an external identity provider. |
|
Gatekeeper |
Protect applications and services by using a dedicated host instance that acts as a broker between clients and the application or service validates, and sanitizes requests and passes requests and data among them. |
|
Gateway aggregation |
Uses a gateway to aggregate multiple individual requests into a single request. |
|
Gateway offloading |
Offloads shared or specialized service functionality to a gateway proxy. |
|
Gateway routing |
Routes requests to multiple services using a single endpoint. |
|
Health endpoint monitoring |
Implements functional checks in an application that external tools can access through exposed endpoints at regular intervals. |
|
Index table |
Creates indexes over the fields in data stores that are frequently referenced by queries. |
|
Leader election |
Coordinates the actions performed by a collection of collaborating task instances in a distributed application by electing one instance as the leader, who assumes responsibility for managing the other instances. |
|
Materialized View |
Generates pre-populated views over the data in one or more data stores when the data isn't ideally formatted for the required query operations. |
|
Pipes and Filters |
Breaks down a task that performs complex processing into a series of separate elements that can be reused. |
|
Priority Queue |
Prioritizes requests sent to services so that requests with a higher priority are received and processed more quickly than those with a lower priority. |
|
Queue-based load leveling |
Uses a queue that acts as a buffer between a task and a service that it invokes to smooth intermittent heavy loads. |
|
Retry |
Enables an application to handle anticipated temporary failures when it tries to connect to a service or a network resource by transparently retrying an operation that's previously failed. |
|
Scheduler agent supervisor |
Coordinates a set of actions across a distributed set of services and other remote resources. |
|
Sharding |
Divides a data store into a set of horizontal partitions or shards. |
|
Sidecar |
Deploys the components of an application into a separate process or container to provide isolation and encapsulation, such as running log and metric agent containers as a sidecar with your main application. |
|
Static-content hosting |
Hosts static contents on cloud provider services, such as AWS S3. |
|
Strangler |
Incrementally migrates a legacy system by gradually replacing specific pieces of functionality with new applications and services. |
|
Throttling |
It helps you limit requests on your service to avoid any DoS or DDoS attacks, and also gives clear implementation logic about how to handle multiple clients' traffic gracefully in a multi-tenant environment. |
|
Valet key |
Uses a token or key that provides clients with restricted direct access to a specific resource or service. |
Note: There are possibilities that the design pattern sub topic may fall into multiple categories, so keep hold of the design pattern mind map in your mind, as we have given more broad and random definitions under a specific design pattern topic and will not duplicate the definition of those design patterns.