Skip to main content

Microservices Design Patterns

What are Microservices​

info

Microservices is an architectural style where Monolith applications are broken into small, independent services which handle a specific business capability or sub-domain. Microservices are loosely coupled and communicate with each other via APIs. In DDD (Domain Driven Design) each Microservice has its own distinct Context, known as bounded context, where all terms and entities have a clear, unambiguous meaning.

Microservices Design Patterns​

Event-Driven Architecture (EDA) Pattern​

  • Microservices architecture has multiple services and maintaining data consistency and data flowing among services can be blocking and cumbersome and damaging to user EX. EDA pattern uses asynchronous (non-blocking) communication between services and improves performance and user EX.
  • Event Producer Services will publish events when their state changes, which are consumed by subscriber services to update their state accordingly. This way, each service can maintain its data consistency.

Distributed Transactions in Microservices​

Saga Pattern​

Command Query Responsibility Segregation (CQRS) Pattern​

  • CQRS stands for Command and Query Responsibility Segregation, a pattern that separates read and update operations for a data store. Implementing CQRS in your application can maximize its performance, scalability, and security.

API Gateway Pattern​

  • Client interacts with provided single entry point for all requests. The gateway handles requests in one place, routes these requests to correct microservices, also performs necessary transformations. See similar aggregator pattern.

Aggregator Design Pattern | Data Mesh​

  • The Aggregator design pattern acts as a gateway, consolidating responses from multiple services into one. Because the client request involves multiple services to provide the required response.

Chain of Responsibility Pattern​

  • Decouples the sender and receiver of a request. Each service in the chain processes the request and decides whether to pass it on to the next service.

Fork-Join | Branch Pattern​

  • Structural design pattern which splits a task into multiple branches or subtasks, processes them concurrently, and then returns combined results.

Shared Database Pattern​

  • This pattern will use one shared database for multiple services.

Resilient Microservice Design Patterns​

  • The ability of the microservices to recover from failures and remain functional to service requests, makes microservices more resilient.

Implement with Resilience4j which offers

  • Circuit Breaker
  • Rate Limiter - block too frequent requests
  • Bulkhead - avoid too many concurrent requests
  • Retry - used to retry a failed call automatically

- Circuit Breaker Pattern​

  • Helps to manage situation better when service is failing. Rather than re-trying request to failing service forever, track the number of failed requests and 'trip' the circuit breaker after a given threshold. So it prevents further requests until the failing service is healthy again.

- Bulkhead Pattern​

  • A ship is built wth multiple compartments using Bulkheads as seals to prevent the entire ship from sinking in case of partial damage.
  • Bulkhead Pattern splits a service in microservices into multiple components with isolated resources, so that failure of one component in service itself or if it is waiting on other failing service, will not bring down performance of remaining components in service.

- Rate Limiter​

  • block too frequent requests

Microservices Deployment Strategies and Patterns​

The microservices deployment pattern is how you update or modifying microservices software components in deployent.

Canary Deployment​

A canary deployment is where new version of microservices will get a small percentage of traffic initially. If it works successfully with only a small percentage of load first, it is given larger workloads. If canaries aren't functioning correctly, traffic can be routed to a stable version.

Canary rollback - if any severe issues are detected, a safe rollback strategy can be used, with switching traffic back to the primary version.

Blue-Green Deployment​

This strategy involves maintaining two identical environments of infrastructure and having current and new Microservice versions simultaneously in production. Blue refers to current and Green refers to new version of microservices. When new version of a microservice passes tests and ready, traffic is switched from blue to green. Microservices are monitored to see performing well or they will be revert back to the blue state.

Rolling Deployment​

Rolling deployment strategy involves updating microservices one at a time while keeping the rest running. There will be mix of new and old version microservices in production till the newer version of the application takes up complete charge.