Microservices Design Patterns

1.?????Aggregator Design Pattern

Aggregator Service – Collects the responses of different services and combines their result and gives it back to the requestor.

Scenario 1: A simple web page can be an aggregator. It invokes multiple services using REST mechanism and then processes/displays the data to the client.

Scenario 2: It could be just another composite service that accesses other services and aggregates the logic.

Other services can then consume it.

For Example, A ProductService could fetch data from ProductDetailsService and InventoryService, then can then be used to display the details to the customers.

2. Chained or Chain of Responsibility pattern

This pattern avoids coupling the client or the request to a single service, instead, the request can be handled by multiple services in the form of a chain and generate a consolidated response.

Note:

• Any service in the chain may or may not handle the request.
• It is possible to create a chain with a single microservice, in view of future expansions.

Example:

Wholesaler: To check the total quantity of a certain product available, the RetailInventoryService, WareHouseInventoryService, PartnerInventoryService, DistributorInventoryService can all chain up and add the quantity respectively and give a consolidated response.

Drawback: All the chaining is synchronous, hence the client/requestor needs to wait until all the services/handlers in the chain finished their processing.

3. Branch pattern:

This pattern extends the earlier discussed Aggregator pattern and Chain of responsibility pattern.

A service can simultaneously call two or more different “chains” of microservices and generate an aggregated?response processing from them.

This pattern can also be used to call different chains, or a single chain, based on the business needs.

Example:

Appraisal System:

When a supervisor logs in, the AppraisalService can call PersonalInformation Service to the information of the logged-in person itself, as well as calls the EmployeeReportingService(which in turn can call other services like AllocationService, ProjectManagementService) to fetch the information with respect to the reportees of the supervisor.

When an employee logs in, who is not a supervisor, then the same AppraisalService can just call the PersonalInformation Service to fetch the data, and Employe EmployeeReportingService eService details would not be called at all.

Advantages:

Branch microservice pattern allows the developer to configure service calls dynamically. All service calls will happen in a concurrent manner, which means service A can call Service B and C simultaneously.

4. Proxy pattern:

This pattern can be considered an aggregator pattern plus a layer of security.

We often do not want to expose the actual URLs of our microservices to the client, hence a dummy proxy layer can be added to translate the URL.

Cross-cutting concerns like authentication/authorization, tracing, audit, and metrics can all be managed in one place.

5. API Gateway Pattern

API Gateway is a server that acts as an API front-end, receives API requests, enforces throttling (rate limiting) and security policies, passes requests to the back-end service, and then passes the response back to the requester.

Cross-cutting concerns like authentication/authorization, tracing, audit, and metrics can all be managed in one place.

An API gateway can be used to construct an API by combining multiple existing services together, which is something that can’t be done with an API proxy.

6. Circuit-Breaker Pattern

Consider a scenario where one of the microservice is down for some reason and doesn’t handle requests. The requests of the caller microservice (Service A) to this faulty service(Service B) keep increasing, thereby increasing the load on Service A and eventually making it faulty.?

This effect can be cascaded to other microservices which try to connect to the faulty services and eventually the entire application would go down.

To avoid this scenario, the microservices are integrated with a proxy which acts as a circuit breaker.?

The integrated proxy service keeps a track of the request timeouts and the failed request to the other microservices. A healthy service is in a CLOSED state.

Once the failure request count reaches a pre-defined value, all the incoming requests are responded with a pre-defined message, with the help of the fallback method, instead of keeping the clients waiting, this is the OPEN state.

After a timeout period, the proxy again tries to establish the connection with the faulty microservice and sends some requests to check the health status, this is the HALF OPEN state.

If requests succeed the proxy service resumes the operations otherwise, it again trips the circuit breaker and starts a timeout period and no requests will be entertained during that period.

7. Service Discovery Pattern

In the world of containerization, IP addresses assigned to service instances change dynamically and one service cannot store the URL of the other services it contacts.

Hence a service registry is needed which keeps a record of all the available instances of all the services.

Any service must register itself in the registry when starting and de-register when it is shutting down.

The registry should also do a health check on all the service registrations and ensure that only working instances are available to be consumed by the requested service.

Client-side discovery: The client connects with the registry and uses an internal load-balancing algorithm to connect with one of the available service instances.

Example: Netflix Eureka, along with Netflix Ribbon

Server-side discovery: The client sends the request to a load balancer, which queries the service registry and routes the request to one of the available service instances.?

Example: AWS Elastic Load Balancer (ELB)

8. Strangler Pattern

This pattern is used when you have to migrate from an already existing Monolithic application to a Microservice-based application.

We definitely do not want to start converting the entire application into a brand-new Microservice-based application, hence this pattern suggests incrementally converting the individual functionalities of the application.

A Strangler fa?ade will route the requests to the legacy applications or modernized microservices.

Both the applications will be running parallelly and slowly the new microservice-based architecture will strangle the old application.

9. Command Query Segregation Pattern

Command??????? Create/Update/Delete data from the database.

Query ?????????????? Read from a Read-only database.

In microservices, each service has its own database, so in scenarios where we need to read data from multiple services, then a read-only replica can be created out of the actual database.

This view-only database can be kept up to date by subscribing to the domain events published by the owner of the database.?

10. Materialized View Pattern

When one microservices frequently requires data from other microservices, then materialized view pattern can be used.

A read-only database can be created, which can be a denormalized view of all the data this service requires to handle the request.

So now, instead of calling the other services multiple times, this service can use the materialized view and process the request, which increases the response time drastically ??.

But, the challenge is to keep this view updated as soon as the data in other databases changes. This can be achieved by a notification mechanism or by running a scheduler that updates the view at regular intervals.

11. Event Sourcing Pattern

So as service needs to send notifications when doing any operation in the database.

But when does it send this notification?

?If it sends before the changes to the database. What happens if the transaction didn’t execute properly?

If it decides to send after the database transaction completes, what happens if the service itself crashes before sending the notification?

?So,

?If the database transaction commits, then messages must be sent. Conversely, if the database rolls back, the messages must not be sent.

?Messages must be sent to the message broker in the order they were sent by the service.

?The ordering must be preserved across multiple service instances that update the same read database.

?How does event sourcing help??

Event sourcing persists the state of a business as a sequence of state-changing events.

Whenever the state of a business entity changes, an event is published.

Since saving an event is a single operation, it is inherently atomic.

The application reconstructs an entity’s current state by replaying the events.

Event sourcing consists of loosely coupled business entities that exchange events.

This makes it a lot easier to migrate from a monolithic application to a microservice architecture.

12. Saga Pattern

When each microservices has its own database, then in many scenarios, a database transaction could span across services.

Therefore, the Saga pattern helps to execute the transaction across databases.

Saga means a sequence of steps, so a sequence of local transactions would be done for the request.?

Each local transaction would then publish a message or event to other services to windup their local transaction. ?

If the local transaction itself publishes events, then it is called Choreography and if the sequence of events is taken care of by an external object, that object is called an Orchestrator.?

If a local transaction is, then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.

This pattern is a little complex to implement as for each local transaction, a compensating rollback transaction should be done if any of the local transactions in the sequence fails.

That's it, folks!

For a hands-on on Microservices, do visit: https://youtube.com/playlist?list=PL3lJzaJRTY_TEwSyaoz8x8zyujx3HcaAv