What is Microservice?
Microservice architecture has become the de facto choice for modern application development. I like the definition given by “Martin Fowler”.
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. — Martin Fowler
Principles of microservice architecture:
- Independent, autonomous
- Decentralized governance
- Failure isolation
- Continuous delivery through DevOps
What are design patterns?
Design patterns are commonly defined as time-tested solutions to recurring design problems. Design patterns are not limited to the software. Design patterns have their roots in the work of Christopher Alexander, a civil engineer who wrote about his experience in solving design issues as they related to buildings and towns. It occurred to Alexander that certain design constructs, when used time and time again, lead to the desired effect.
Why we need design patterns?
Design patterns have two major benefits. First, they provide you with a way to solve issues related to software development using a proven solution. Second, design patterns make communication between designers more efficient. Software professionals can immediately picture the high-level design in their heads when they refer the name of the pattern used to solve a particular issue when discussing system design.
Microservices is not just an architecture style, but also an organizational structure.
Do you know the “Conway’s Law”?
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. — Melvin Conway, 1968
Microservices Design patterns:
Aggregator Pattern — It talks about how we can aggregate the data from different services and then send the final response to the consumer/frontend.
- Proxy Pattern — Proxy just transparently transfers all the requests. It does not aggregate the data that is collected and sent to the client, which is the biggest difference between the proxy and the aggregator. The proxy pattern lets the aggregation of these data done by the frontend.
- Chained Pattern — The chain design pattern is very common, where one service is making call to other service and so on. All these services are synchronous calls.
- Branch Pattern — A microservice may need to get the data from multiple sources including other microservices. Branch microservice pattern is a mix of Aggregator & Chain design patterns and allows simultaneous request/response processing from two or more microservices.
- Shared Resources Pattern — One database per service being ideal for microservices. This is anti-pattern for microservices. But if the application is a monolith and trying to break into microservices, denormalization is not that easy. A shared database per service is not ideal, but that is the working solution for the above scenario.
- Asynchronous Messaging Pattern — In an message based communication , the calling service or application publish a message instead of making a call directly to another API or a service. An message consuming application(s) then picks up this message and then carries out the task. This is asynchronous because the calling application or service is not aware of the consumer and the consumer isn’t aware of the called application as well.
There are many other patterns used with microservice architecture, like Sidecar, Event Sourcing Pattern, Continuous Delivery Patterns, and more. The list keeps growing as we get more experience with microservices.
Let me know what microservice patterns you are using.
Thank you for reading :)