Microservices Design principle & Design patterns

12 min readJan 30, 2023

MICROSERVICE S

Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams.

MICROSERVICE’S DESIGN PATTERN AND ARCHITECTURE:

The benefits of microservices are that each one typically encapsulates simpler business functionality, which you scale up or down, test, deploy, and manage independently. The goal of microservices is to increase the velocity of application releases, by decomposing the application into small autonomous services that can be deployed independently. A microservices architecture also brings some challenges. The design patterns shown here can help mitigate these challenges.

Ambassador can be used to offload common client connectivity tasks such as monitoring, logging, routing, and security (such as TLS) in a language agnostic way. Ambassador services are often deployed as a sidecar.

Anti-corruption layer implements a façade between new and legacy applications, to ensure that the design of a new application is not limited by dependencies on legacy systems.

Backends for Frontends creates separate backend services for different types of clients, such as desktop and mobile. That way, a single backend service doesn’t need to handle the conflicting requirements of various client types. This pattern can help keep each microservice simple, by separating client-specific concerns.

Bulkhead isolates critical resources, such as connection pool, memory, and CPU, for each workload or service. By using bulkheads, a single workload (or service) can’t consume all of the resources, starving others. This pattern increases the resiliency of the system by preventing cascading failures caused by one service.

Gateway Aggregation aggregates requests to multiple individual microservices into a single request, reducing chattiness between consumers and services.

Gateway Offloading enables each microservice to offload shared service functionality, such as the use of SSL certificates, to an API gateway.

Gateway Routing routes requests to multiple microservices using a single endpoint, so that consumers don’t need to manage many separate endpoints.

Sidecar deploys helper components of an application as a separate container or process to provide isolation and encapsulation.

Strangler supports incremental refactoring of an application, by gradually replacing specific pieces of functionality with new services.

MICROSERVICES: DESIGN PRINCIPLES

Single Responsibility Principle (SRP).
Build Around Business Capabilities.
Fault tolerance — Resilient.
Failure Isolation — POD — Container.
Decentralized Data / DB — POD — PVC.
Loose Coupling.
CI/CD — DEVOPS — Auto — Jenkins /OpenShift.
Continuous Monitoring — Prometheus / Dynatrace.
Distributed Tracing Monitoring — APM /Zipkin.
Hexagonal Structure.

MICROSERVICE DESIGN:

In designing any architecture, we need to have certain guardrails. One such framework is the “The Twelve Factors” which is helpful in formulating micro-services and on-boarding them to cloud for scalability and faster time to market.

I. Codebase

One codebase tracked in revision control; many deploys.

II. Dependencies

Explicitly declare and isolate dependencies

III. Config

Store config in the environment

IV. Backing services.

Treat backing services as attached resources.

V. Build, release, run.

Strictly separate build and run stages.

VI. Processes

Execute the app as one or more stateless processes.

VII. Port binding

Export services via port binding

VIII. Concurrency

Scale out via the process model.

IX. Disposability

Maximize robustness with fast startup and graceful shutdown.

X. Dev/prod parity

Keep development, staging, and production as similar as possible.

XI. Logs

Treat logs as event streams

XII. Admin processes

Run admin/management tasks as one-off processes.

MICROSERVICE DESIGN PATTERN & ARCHITECTURE:

DECOMPOSITION PATTERN (By Business Capability, Subdomain, Strangler Pattern, Bulkhead Pattern, Side car Pattern)
INTEGRATION PATTERN.
DATABASE.
OBSERVABILITY PATTERN.
CROSS — CUTTING CONCERNS PATTERN (External Configuration, Service Discovery, Circuit Breaker, Blue Green Deployment, Canary deployment, Strategy deployment Pattern).

DESIGN PATTERS FOR MICROSERVICE:

1.Database per microservice:

When a company replaces a large monolothic system with several smaller microservices, the most important decision would be about the database. Many architects favor keeping the database as is, but the short-term benefit is an anti-pattern, particularly in a big-scale system.

Complete data to a service ownership
Loose coupling among the development teams building the services.
The application is more resilient.
Individual data stores are easier to scale.
Polyglot persistence that enables the use of various database technologies for different microservices.

2.Aggregator pattern:

In computing, Aggregator refers to a program or website that gathers related data items and displays them. Thus, Aggregator in Microservices patterns is a basic web page that invokes different services to get the information or achieve the functionality required. Moreover, since the output source is divided on breaking the monolithic architecture to microservices, the pattern proves beneficial when you require an output.

With its unique transaction ID, the Aggregator could collect the data from every microservice, apply business logic, and publish it as a Rest end point. The collected data, later on, could be consumed by the respective services that require the data collected.

3.API Gateway

The pattern is suitable for big apps with multiple client applications and is responsible for providing a single-entry point for a certain microservices group. The API Gateway sits between the microservices and client applications and is a reverse proxy. Some cross-cutting services it can provide include SSL termination, authentication, and caching.

The API gateway is capable of handling partial failures and could deal with partial failures in different ways. Instead of providing a one-size-fits-all API style, this pattern could expose a different API for every client. Furthermore, the pattern could also implement security and verify that the client is authorized to make the request.

4.Circuit Breaker

The Circuit Breaker pattern could come to the rescue if a service failure could lead to cascading failures throughout the application. The pattern could have the following three states, such as the following:

Open — request from the Microservice immediately fails, and an exception is returned. The circuit breaker, after a timeout, goes to a Half-Open state.
Closed — routes requests to the Microservice and counts the number of failures. If the number of failures at a certain time exceeds a threshold, it trips to Open State.
Half-Open — only a small number of requests are allowed to pass and invoke the operation. The circuit breaker goes to a Closed state if the requests are successful, and if a request fails, it will go to the Open state.

5.Decomposition Patterns

Decompose by Business Capability Microservices is all about making services loosely coupled and applying the single responsibility principle. It decomposes by business capability. Define services corresponding to business capabilities. A business capability is a concept from business architecture modeling [2]. It is something that a business does in order to generate value. A business capability often corresponds to a business object, e.g.

Order Management is responsible for orders.
Customer Management is responsible for customers.

Decompose by Subdomain

Decomposing an application using business capabilities might be a good start, but you will come across so-called “God Classes” which will not be easy to decompose. These classes will be common among multiple services. Define services corresponding to Domain-Driven Design (DDD) subdomains. DDD refers to the application’s problem space — the business — as the domain. A domain is consisting of multiple subdomains. Each subdomain corresponds to a different part of the business. Subdomains can be classified as follows:

Core — key differentiator for the business and the most valuable part of the application
Supporting — related to what the business does but not a differentiator; can be implemented in-house or outsourced.
Generic — not specific to the business and are ideally implemented using off the shelf software.

The subdomains of an Order management include:

Product catalog service
Inventory management services
Order management services
Delivery management services

Decompose by Transactions/Two-Phase Commit (2pc) Pattern

This pattern can decompose services over the transactions. Then there will be multiple transactions in the system. One of the important participants in a distributed transaction is the transaction coordinator [3]. The distributed transaction consists of two steps:

Prepare phase — during this phase, all participants of the transaction prepare for commit and notify the coordinator that they are ready to complete the transaction!
Commit or Rollback phase — during this phase, either a commit or a rollback command is issued by the transaction coordinator to all participants.

The problem with 2PC is that it is quite slow compared to the time for operation of a single microservice. Coordinating the transaction between microservices, even if they are on the same network, can really slow the system down; so, this approach isn’t usually used in a high load scenario.

6.Strangler Pattern

The first three design patterns that you went through were decomposing applications for Greenfield, but 80% of the work you do is with brownfield applications, which are big, monolithic applications (legacy codebase). The Strangler pattern comes to the rescue or solution. This creates two separate applications that live side by side in the same URI space. Over time, the newly refactored application “strangles” or replaces the original application until finally, you can shut off the monolithic application. The Strangler Application steps are transformed, coexist, and eliminate:

Transform — Create a parallel new site with modern approaches.
Coexist — Leave the existing site where it is for a time. Redirect from the existing site to the new one so the functionality is implemented incrementally.
Eliminate — Remove the old functionality from the existing site.

7.Bulkhead Pattern

This pattern isolates elements of an application into pools so that if one fails, the others will continue to function. This pattern is named Bulkhead because it resembles the sectioned partitions of a ship’s hull. Partition service instances into different groups, based on consumer load and availability requirements. This design helps to isolate failures and allows you to sustain service functionality for some consumers, even during a failure.

8.Sidecar Pattern

This deploys components of an application into a separate processor 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, is created and retired alongside the parent. The sidecar pattern is sometimes referred to as the sidekick pattern and is the last decomposition pattern that we show in the post.

9.Blue-Green Deployment Pattern

With microservice architecture, one application can have many microservices. If we stop all the services then deploy an enhanced version, the downtime will be huge and can impact the business. Also, the rollback will be a nightmare. Blue-Green Deployment Pattern avoids this. The blue-green deployment strategy can be implemented to reduce or remove downtime. It achieves this by running two identical production environments, Blue and Green. Let’s assume Green is the existing live instance and Blue is the new version of the application. At any time, only one of the environments is live, with the live environment serving all production traffic. All cloud platforms provide options for implementing a blue-green deployment.

MICROSERVICE BENEFITS:

DevOps mindset — You Build It you run it — followed by Amazon.

Messaging over a lightweight message bus — for e.g., RabbitMQ or ZeroMQ.
Patterns with replaceability, upgradeability and modularity by design.
XP programming mantra — YAGNI” — You Aren’t Going to Need It — do not build the microservice until you need it.
Microservices architecture focuses on a responsive-actor programming style.
Each of these services can be deployed, tweaked, and then redeployed independently without compromising the integrity of an application.

MICROSERVICE CONNECTION WITH OTHER TECHNOLOGIES:

Microservices architecture forms the base for products being built at companies like Amazon, Netflix, Spotify, and Uber.

Despite these benefits, microservices architecture also comes with its own challenges, from implementation to migration and maintenance. Some of the prominent challenges adopting a microservices architecture poses include:

The operation of a microservice system requires more effort than running a deployment monolith, since many more deployable units exist.
Since all testing must be done independently, one microservice can block the test stage and prevent the deployment of the other microservices.
Changes that affect multiple microservices are more difficult to implement than the changes that concern several modules of a deployment monolith.

1. Docker and Kubernetes

Docker is a software platform that allows you to build, test, and deploy software as self-contained packages called containers. These Docker containers can be deployed anywhere, and each container contains all the resources and configuration it needs to run.

Kubernetes acts as a complement to Docker, especially at scale. It’s typically used to help tackle some of the operating complexities when moving to scale multiple containers, deployed across multiple servers. Docker and Kubernetes can be used together to act as a flexible base for your microservices-based system, easily scaling up as the workload increases or vice versa.

Benefits of Docker for Microservices

Docker is a lightweight option for building a microservices architecture. All components of a microservice can be packed into a Docker image and remain isolated from other microservices. Docker makes it easy to deploy your software as you only have to distribute Docker images using Docker files. With Docker Compose, multiple containers can be coordinated to build an entire system of microservices with containers. We can also use Docker Machine to install Docker environments on a server.

2.REST

Microservices have to communicate with other microservices. One tool that can be used for this is REST (Representational State Transfer). REST is an architectural design pattern for building RESTful APIs. REST allows services to communicate directly via HTTP. Requests and responses are handled in standard formats like XML, HTML, or JSON.

Benefits of REST for Microservices

REST is a great tool for building a scalable microservice, since they are stateless and modular. The REST pattern allows the client and the server to be implemented independently without the knowledge of the other entity. This means that code at either side can be modified without affecting each other.

3.Prometheus

Prometheus is an open-source systems monitoring and alerting tool originally developed at SoundCloud. It implements a multi-dimensional data model and provides data store and data scrapers. Data is stored as key-value pairs in memory cached files. Prometheus uses a simple query language that forms the foundation of task monitoring. This includes visualization features for alters and statistics.

Benefits of Prometheus for Microservices

For microservices, Prometheus’s support for multi-dimensional data collection and querying is a particular strength. Prometheus also offers an extensible data model, which allows you to attach arbitrary key-values dimensions to a time series. Prometheus is known for its simple design and ability to create minimalist applications, so Prometheus is ideal for simple microservice-based applications. It is also useful for distributed, cloud-native environments.

4.Redis

Redis is an open source, in-memory data structure store. It is one of the most popular key-value or NoSQL databases. Although it is an in-memory database, it provides support for persisting data, master-replica replication, and it performs well when compared to traditional database systems.

Benefits of Redis for Microservices

As we know, microservices must maintain their own state using a database. Service data should be isolated from other data layers to enable uncoupled scaling. Redis, alongside Redis clustering or Redis Sentinel, fits many of these requirements, including low-latency final response. Redis can be leveraged by your application in many different ways. Redis is widely used in microservices architecture because it can serve as a cache or as the service’s primary database. Depending on your requirements, Redis can also act as a message broker or cache.

THANKYOU !