Category: microservices Design Patterns

Microservices Design Patterns – Health Check ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. Now in case a database is down or cannot afford more connections then a monitoring system should raise alerts. Loadbalancer/service registry/api gateway should not redirect any request to such failed service instances. So we need to detect if a running service instance is able to take request(s) or not. Solution We can add a health check point to each service e.g. HTTP /health which returns the status of service health. This endpoint can perform the following tasks to check a service health − Connections Availablity − Status of database connections or connections to infrastructure services used by current service. Host Status − Status of host like disk space, cpu usage, memory usage etc. Application specific logic − business logic determining service availablity. Now a monitoring service e.g. load balancer, service registry periodically invokes the health check endpoint to check the health of the service instance. Print Page Previous Next Advertisements ”;

Distributed Tracing ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. Requests often span multiple services. Using external monitoring, we can check overall response time and no. of invocations but how to get insight on individual transactions/operations. A service may use databases, messaging queues, event sourcing etc. How to track scattered logs across multiple services? Solution We can instrument a service which is designed to perform the following operations − Corelation ID − Generate a unique external request id per external request and pass this external id to each service involved in processing the request. Log the Corelation ID − Each log message generated by processing service should have this correlation id. Record the Details − Records the start/end time and other relevant details in logs when a request is processed by a service. Searchable Logs As logs should be placed at a centralized location, following diagram showcase how to use Kafka, LogStash and Kibana to aggregate logs and search the indexed logs using required filters. Microservices generates logs, which are published using kafka log appender which then output the log messages to kafka cluster. LogStash ingests the messages from kafka, transforms the messages and publish to elastic search container. Now kibana provides a visual interface to search/read indexed logs from elastic search container and provides required filters. Print Page Previous Next Advertisements ”;

Microservices Design Patterns – Saga ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment and if we”ve used a database per service design pattern then how to implement a transaction which spans multiple services. Solution We can use Saga Pattern. A saga is a sequence of local transactions. In this pattern, each transaction updates the database and triggers an event or publishes a message for next transaction in saga. In case, any local transaction fails, saga will trigger series of transactions to undo the changes done so far by the local transactions. Consider an example of order service and customer service. Order service can make an order and then ask customer service if credit limit is crossed or not. In case credit is crossed, the customer service will raise an event to order service to cancel the order otherwise to place the order successfully. In order to implement this pattern, we often need to Choreography based saga or Orchestrator based saga. In choreography based saga, services handles the domain events during local transactions and either complete the transaction or undo the same while in orchestrator based saga, an orchestrator object handles events during local transactions and then tell coordinate which local transaction is to be executed. Print Page Previous Next Advertisements ”;

Microservices Design Patterns – Circuit Breaker ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. These services often interacts with other microservices. Now there is always a possibility that a service is overloaded or unavailable. In such a case the caller service will also wait. If multiple services are getting blocked then it will hamper the performance and can cascade the impact on overall application. Now, how to prevent a service failure or network failure from cascading to other services. If one service is down then it should not be given further requests. Solution We can use circuit breaker pattern where a proxy service acts as a circuit breaker. Each service should be invoked through proxy service. A proxy service maintains a timeout and failures count. In case of consecutive failures crosses the threshold failures count then proxy service trips the circuit breaker and starts a timeout period. During this timeout period, all requests will failed. Once this timeout period is over, proxy service allows a given limited number of test requests to pass to provider service. If requests succeed the proxy service resumes the operations otherwise, it agains trips the circuit breaker and starts a timeout period and no requests will be entertained during that period. Print Page Previous Next Advertisements ”;

Service Discovery ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. These services often run in containerized/virtual environments and their number of instances and location changes dynamically. So we require a mechanism to enable client of a microservice to make requests to dynamically changing service instances. Solution We can use Service Discovery pattern. To implement this pattern, we need a router/load balancer running at a particular fixed location and a service registry where all microservice instances are registered. Now a client makes a service request, it will come to the load balancer which then inquires the service registry. If service instance is available, then the request is redirected to the available service instance. Print Page Previous Next Advertisements ”;

Microservices Design Patterns – Aggregator ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, we often need to get the combined result of multiple microservices and show on the application. Solution We can define an Aggragator as a simple web module will act as a load balancer, which means it will call different services as per requirements. Following is a diagram depicting a simple microservice web app with aggregator design. As seen in the following image, the “Aggregator” is responsible for calling different services one by one. If we need to apply any business logic over the results of the service A, B and C, then we can implement the business logic in the aggregator itself. An aggregator can be again exposed as another service to the outer world, which can be consumed by others whenever required. While developing aggregator pattern web service, we need to keep in mind that each of our services A, B and C should have its own caching layers and it should be full stack in nature. Print Page Previous Next Advertisements ”;

Decompose By Strangler ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service should be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, the major problem is how to design loosely coupled microservices or to break a large application into small loosely coupled services? Solution We can define a microservice using strangler pattern. A strangler application has two types of services − Existing Behavior − These services exhibits the behavior that previously resides in Monolith. New Functionalities − These services implements new behavior. So over the time of development, microservices increases and monolith shrinks with features moving out from monolith to Strangler Application. Example Consider an example of an Online Book Store. Initially we have only developed Book Catalog management service and other services are supported in legacy monolith application. During the course of development, more and more services are developed and functionalities are moved away from a monolith. So when a new service is developed, the monolith is strangled, the old component is decommissioned and new microservice is deployed and supports the new functionality. A strangler pattern can be implemented using three steps − Transformation − Develop the microservices independently to implement a particular functionality of a monolith. Co-Exist − Both Monolith and Microservices will work. User can access functionality from both components. Elliminate − Once the newly developed functionality is production ready, remove the functionality from the monolith. Advantages Test Driven Development − As services are developed in chunks, we can use TDD for business logic and ensure the code quality. Independent Teams − Teams can work in parallel fashion on both monolith and microservices thus making a robust delivery mechanism. Print Page Previous Next Advertisements ”;

Microservices Design Patterns – API Gateway ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, microservices can use different protocols. For example, some microservices are using REST and some are following AMQP. Now problem is how to allow clients to access each microservice seemlessly without worrying about protocols and other intricacies. Solution We can define an API Gateway which will acts as single entry point for all type of clients. Following are the other benefits of API Gateway − Simple Proxy − API Gateway can acts as simple proxy to some requests to redirects them to relevant service. Multiple Services − API Gateway can redirects call to multiple services. Client Specific API − API Gateway can provide client specific API as well, like a different API for Desktop version than a Mobile Application. Protocol Handling − API Gateway handles the communication protocols to each service call internally and clients are concerned only with request/response. Security and Authentication − API Gateway can implement a security that each request goes to service only after authentication and authorization. Example Consider an example of an Online Book Store. API Gateway allows to use the online Book store APIs on multiple devices seemlessly. Advantages Client Insulation − Clients are insulated from knowing the location of microservices or how to call them. Multiple Service Calls − API Gateway can handle multiple services and give result as one and thus can reduce the round trips and increase the performance. Standard Interface − API Gateway provides a standard interface to Clients to get responses from microservices. Print Page Previous Next Advertisements ”;

Microservices Design Patterns – Proxy ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, we often need to prepare a unified interface which can do the common work like authentication and authorization before each service call. Solution Proxy microservice pattern is a variation of the aggregator model. In this model we will use proxy module instead of the aggregation module. Proxy service may call different services individually. In Proxy pattern, we can build one level of extra security by providing a dump proxy layer. This layer acts similar to the interface. Advantages Proxy pattern provides a uniform interface instead of different interface per microservice. Proxy pattern allows to apply uniform concerns like logging, security etc at one place. Print Page Previous Next Advertisements ”;

Decompose By Subdomain ”; Previous Next Problem Statement Microservice architecture structures an application as a set of loosely coupled microservices and each service should be developed independently in agile manner to enable continous delivery/deployment. When a large, complex application is to be built using microservice architecture, the major problem is how to design loosely coupled microservices or to break a large application into small loosely coupled services? Solution We can define a microservice corresponding to Domain-Driven Design(DDD) subdomains. DDD refers to business as a domain and a domain can have multiple subdomains. Now each subdomain refers to different areas. For Example − Order Management − Order Management subdomain refers to Orders. Customer Management − Customer Management subdomain refers to Customers. Subdomains can be further classified using following criterias − Core − Most important and key differentiator of an application. Supporting − Business related and are used to support the business activities. Generic − Not specific to business but are used to enhance the business operations. Example Consider an example of an Online Book Store. It can have following subdomains and corresponding microservices − Books Catalog Management Inventory Management Order Management Warranty Management Advantages Stable Architecture − As business subdomains are stable, this architecture is highly stable. Cross-functional Teams − Development Teams works independently, are cross-functional and are organized around functional features instead of technical features. Loosely Coupled Services − Developed services will be loosely coupled and cohesive. Dis-advantages Need good understand of Business − Business subdomains needs be indentified after understanding the business. Understanding organizational structure can help as organizations are structured based on their capabilities. High Level Domain Model needed − Business domain objects required as they corresponds to business subdomains. Print Page Previous Next Advertisements ”;