Microservices Design Principles PDF

Design Principles and Patterns for Microservices • Design Principles for Microservice Architecture • Microservice Design Patterns

Microservices • Microservices, also referred to as microservice architecture is an architectural design that allows an application to be structured as a collection of smaller, selfcontained services that are built around a business domain. Each service of microservice Architecture is self-contained and can implement only one specific business capability.

Design Principles for Microservice Architecture: The following are the design principles for Microservices: • • • • • • • • • •

Services that are self-contained and autonomous Scalability Load Balancing in Real-Time Auto-Provisioning Decentralization Resilient Services Availability DevOps integration ensures continuous delivery.

Continuous Monitoring and Seamless API Integration Isolation from Setbacks

Microservice Design Patterns: • Aggregator Pattern In the world of computing Aggregators is a program or website that stores and displays relevant elements of data. This is why Microservices patterns Aggregator is a basic website that calls different services to get the information required or to achieve the desired function. The source of output is split into a monolithic system broken down into microservices this approach is beneficial when combing data from various services. Both services have their own databases, and an aggregator with a unique transaction ID will take data from each microservice, use business logic, and finally publish it to an endpoint to rest.

• Asynchronous Messaging: Each of the services within this kind of Microservices Design Pattern is able to communicate with one another however they don't need to talk in a sequential manner. Therefore, look at three of the services which are: Service A, B as well as Service C. A client's request may be sent directly via Services C or Service B simultaneously. They will route the request to the queue. Apart from that, the request may be directed to Service A and the reply is not required to be given to the same company that the request was made.

• API Gateway: API gateways have the capability of changing protocol requests between different types. Similarly, it can offload the microservice's authentication/authorization responsibilities. API Gateway also serves as a gateway to all microservices and creates specific APIs that are suited to various kinds of clients. Microservices utilize Service Discovery as a guide to decide on the best route to communicate with each other. Microservices communicate with each other through the use of a stateless server like an HTTP request/message bus.

• Event Sourcing This design style creates events when the state of the application is changed. Furthermore, the events are stored in a series of events, which helps developers in determining what changes were made at the time. This means that it is possible to modify the state of your application to reflect previous changes. Changes in the state of your application will be seen on the display layer after the events have been published.

• Command Query Responsibility Segregator: The database-per-service model, or the shared model of a database for each service employed in all microservices designs. But, since access to data is restricted to one database in the model of a database per service and we cannot implement queries. In this scenario Command, segregator pattern Query Responsibility can be utilized. This application is split into two components based on this pattern which are Command and the Query. The command component will manage any request (such as create deletion, create, and delete) and the query portion will manage materialized views.

• Shared Data or Database: The Microservice API is able to access databases or shared data for each service. This means that each microservice will be assigned its own unique database ID which blocks other applications in the system from accessing the database. In addition, you can also select shared databases to connect more than one microservice's database to address the problem of denormalization. This can help with data collection for monolithic apps which have been split into microservices. But, databases must be limited to 3 microservices.

Otherwise, scaling these services is difficult.