Microservices Architecture : Shared Functionality — Library or Service !!!
In a Microservice Architecture, a service is modeled around a business domain to have a well defined boundary context. This helps teams to be more autonomous and deploy their service as and when needed (also referred as Independent Deployability), without impacting other business functionality.
But, at the same time you also happen to have some piece of functionality which is cross cutting in nature and is needed by roughly all the services. Examples of such shared functionality could be — Logging, Auditing, Rate Limiting, Authentication & Authorization, Data Validation, Circuit Breaker and Retries implementation, and many more.
How do we handle these cross cutting concerns or a set of functionality to be shared across services??? There are a couple of ways by which this can be handled and off-course, each having its own set of complexities and hence a trade-off analysis is must depending on the context of your application.
Let’s understand the two approaches in detail and then we will do a trade off analysis between the two —
Approach 1 — Create the shared functionality as a Shared Library
The approach is very much self explanatory and seems a pretty straight forward stuff from implementation point of view —
- Create a library
- Let everyone know that such a library exists
