How to scope a microservice?
It is always exciting to create new microservices as it gives us so many things to look forward to - a fresh codebase, a new tech stack, or even maybe a clean CICD setup. But does this mean we should create as many microservices as possible?
Whenever we decide to create a new microservice, it is very important to understand its scope of it. If you create a new service for every utility then you are effectively creating a mesh of network calls that is prone to a cascading failure. If your scope is too big, it would lead to the classic problem of a monolithic codebase.
There are a couple of guiding principles that would help us with scoping of microservice.
Loose Coupling
Services are loosely coupled if changes made in one service do not require a change in other. This is the core ideology behind microservices as well, but while designing a system we tend to forget it.
Say, we have an Orders service and a Logistics service. These services are loosely coupled when they do not share anything in common and are communicating with each other via API contracts.
To achieve loose coupling, make your microservices expose as little information as possible. The other service should just know how to consume the data and that is it. No internals, no extra details.
High Cohesion
The principle of High Cohesion says that the related behavior should sit together as part of one service while the unrelated ones should be separate. This would encourage services to be operating independently.
If the Orders service also owns the customer data then when the changes are deployed in one might affect the other module. So the scope of testing before taking things to production increases.
If there is a very strong coupling between the services then it may also happen that the changes in one lead to deploy a few other services- all at the same time. Deploying multiple services at the same time is very risky; because one glitch and the almost entire product is down.
Hence it is not favorable for heterogeneous components to be part of the same service. Keep it crisp and short; and while designing try to keep services loosely coupled and split it to a level where the unrelated components are split up.
Here's the video of my explaining this in-depth ?? do check it out
Microservices are extremely tempting and you will always feel like writing a new service for every problem at hand. You might build a service with very fine-grained responsibilities or you can build one that covers a big spectrum. So, what is the best approach? How should you decide?
In this video, we talk about ways to model and scope a microservice such that the architecture remains robust and flexible; and to achieve this we use the two key guiding concepts - Loose Coupling and High Cohesion.
领英推荐
Outline:
You can also
Thank you so much for reading ?? If you found this helpful, do spread the word about it on social media; it would mean the world to me.
Yours truly,
Arpit
Until next time, stay awesome :)
I teach a course on System Design where you'll learn how to intuitively design scalable systems. The course will help you
I have compressed my ~10 years of work experience into this course, and aim to accelerate your engineering growth 100x. To date, the course is trusted by 600+ engineers from 10 different countries and here you can find what they say about the course.
Together, we will build some of the most amazing systems and dissect them to understand the intricate details. You can find the week-by-week curriculum and topics, benefits, testimonials, and other information here https://arpitbhayani.me/masterclass.
Storyteller | Linkedin Top Voice 2024 | Senior Data Engineer@ Globant | Linkedin Learning Instructor | 2xGCP & AWS Certified | LICAP'2022
2 年Insightful share ???? Arpit Bhayani
More about me: arpitbhayani.me Subscribe #AsliEngineering for such in-depth engineering concepts: https://www.youtube.com/c/ArpitBhayani Check out my System Design course: arpitbhayani.me/masterclass