Microservice Architecture, Its Design Patterns And Considerations

Important Design Patterns

There are several patterns in microservices architecture, but some of the important are discussed below.

Strangler

This pattern addresses the incremental transformation to Microservices architecture from a Monolithic application. Old functionality is replaced by new services, and the latter is put to use after completion while the former is strangled.

The facade interface plays a vital role in the process where services are exposed to the external world when separated from the monolith. So, clients will know the new services behind the facade, and this will obscure the old system.

API Gateway

This provides single entry point for all services, instead of the client directly communicating with each service. API gateway provides aggregation, authentication, caching, etc.

API gateway helps in achieving the following factors:

Security

API gateway does not expose services to the external world directly to secure them. All security-related issues are handled at gateway, and only authenticated clients will gain further access.

Cross-cutting concerns

Concerns such as authentication, SSL termination, rate limiting, request throttling, caching, and more that need to be implemented in each service are the responsibility of gateway.

Coupling

Clients interact with services through the API gateway, which makes it more loosely coupled.

Aggregator

Some requests require several services, which makes increases in the chattiness of client with services. Aggregator can communicate with all services and return a response after aggregation to reduce extensive communication from the client to services.

Saga Pattern

This pattern helps in transaction management where local transaction in each service (saga) take place, and emit an event for next service to start transaction. If any of the transactions fail, a series of transactions that compensate for the previous transaction will be executed by saga to undo any changes made by local transactions that preceded this one.

Below are two means of implementing Sage pattern:

Choreography

In choreography, the point of control is not centralized, which means that each service will publish a message or event for other services by triggering local transaction.

Orchestration

Orchestration provides a way to control the saga participants (services) by telling each service about the local transaction they need to execute. On an event basis, the operations for saga and transactions are handled by the saga orchestrator. The state of an individual task is managed by saga, and in case of failure, it will execute the transaction to compensate for previous transactions.

Asynchronous Messaging

Some requests are compute-extensive and require longer times, which can exceed the timeout limit. For those requests, there must be an asynchronous mechanism in place using message broker services like Azure Service Bus Queue. This helps in processing a large message, and in responding to the requested service after completion.

Circuit Breaker

Some failures can be transient, but some are not. Tlatter system should not exhaust the resources. Instead, break the request flow there and return the exception back immediately. This pattern helps in a situation where the Retry pattern can cause a waste of time and resources, as retrying is not required at all. A timer is used to check whether the system that was failing is recovered enough to be used or not.

This pattern is different from the retry pattern because here the point is not to hope for a successful result by retrying, but rather to save resources from being used unnecessarily. A circuit breaker pattern can avoid the operations that are likely to fail.

This behaves as a proxy for any operation that has the chance to fail. The number of failures is monitored and used for decision if they exceed a specified threshold. There are three states that are similar to a circuit breaker in electronics, as follows:

Closed

The operation to be performed is invoked by a request. The failure count is maintained by proxy and incremented in case of unsuccessful operation. If the number of failures exceeds the threshold for a specified time, then Open is the new state that proxy enters. Here it also starts the timer, and after timeout, the state of proxy will change to Half-Open.

Open

The exception is returned immediately to the application after receiving the request.

Half-Open

Few requests, limited in number, are allowed to pass on to invoke an operation. Upon successful response from the operation, the state of proxy will change to Closed. If failure occurs again, then the proxy will go into an Open state and restart the timer.

Benefits

• Smaller team sizes with different skill sets lead to the utilization of the best from each language and framework.
• Faster and independent deployments where the real usage of continuous integration and deployment comes into action.
• Testing each service is easy and less time-consuming, because services are domain-specific to their own data store.
• Diverse technologies can contribute toward a complete solution. Upgrading from one technology to another is also trivial.
• Change in the service will not affect the complete system, which results in high reliability.

Drawbacks

• Infrastructure is very costly as different technologies have different testing methodologies, environments for each service, and deployments.
• Debugging can become cumbersome due to different logs of each service and identification of bugs in the actual service.
• Polyglot microservices have some side effects as well, where a company needs to maintain resources for each technology used for developing services.

Summary

Here I’ve discussed microservice architecture, along with comparing it with Monolithic architecture. I have briefly compared their characteristics for further understanding. Important design patterns were also briefly discussed, along with benefits and drawbacks of each architecture.