Update the Load Balancer. The gateway service. Migrate some data. Set up some feature flags. Consume the new endpoints from the Frontend. And of course, don’t forget to add some alarms.
Wait. I’m sure you didn’t expect that you had to do that huge amount of work only for creating a new backend service. Because in the end, was it worth doing so?
Well, that’s exactly what we are about to cover in this post.
We’ll cover:
- When and why is it worth creating a new backend service
- Long-term implications of doing so
- Short-term implications
- Real-life scenarios
- Conclusions
When and why is it worth creating a new backend service
First things first. When you use a microservices architecture, (which I guess you do because you are reading this post), you get different benefits:
- Moving fast (Business Agility)
- More manageable teams
- Own codebase
- Business-model organized services
- Continuous delivery and deployment
But the key point we want to remark here is when is it worth the effort put into creating this service. We need to take into consideration the business or domain that this service will cover.
So, generally speaking, when do we need to create a new service?
- When we need to split some kind of feature into a new business-domain related project.
- When the DB we were using in the previous service is getting huge.
- When the previous service itself is growing until is no longer manageable.
- Or, sometimes, when the migration of the data takes even more time than creating the new service.
Long-term implications
We can’t forget the long-term implications of creating a new service. As this of course depends on how a company supports this internally, we’ll need to:
- Maintain its DB
- Keep communication between services simple
- Keep proper logging and monitoring
- Keep automated deployment and delivery of it
- Keep 80-90% test coverage rate.
Short-term implications
Regarding the short-term implications, this might be the hardest part while creating/migrating to a new service. Some of them are the following ones:
- Update the Load Balancer.
- Update your gateway service.
- Migration of the data: make sure to do our migration (when in production) without impacting customers and keeping proper versioning of the data.
- Set up the needed feature flags.
- Consume the new endpoints from the Frontend.
- Create the necessary alarms and metrics (for example, in Cloudwatch).
- Set up the Graphana dashboards we’ll need to use.
- And so on and so forth, depending on your concrete company and stack.
Real-life scenarios
I’ve recently been asked about a similar issue while doing a system design interview for a huge corporate company. I basically had a monolith service and had to start splitting it depending on the business domains. So here’s a similar example:
We have a, for example, car rental company, and after launching our MVP product, we want to start customizing the notifications/emails we send to our users. We’ll need to split our “Main” service and create a new microservice, let’s call it “Notification Service”.
And so we create our new NotificationService. BUT, during our thought process, we remember: what if the service fails? Besides, notifications need to be sent anyways, they are not always urgent, right? (Especially if they are reminder emails). Would this be a good time to use Event-Driven Architecture?
Of course, we are not going to talk about Event-Driven Architecture in this post, as it would be too big and we don’t want to cover such an extent topic here, but I hope you get the point I’m making here. Business and technical implications are not that simple, and we should consider everything before splitting an existing service into two or more.
Conclusions
So, to summarize, I hope the next time you have a decision-making meeting about creating a new microservice or doing a migration, you evaluate all the aspects involved in doing so.
I really hope you found this post useful! If that was the case, it would be amazing if you could share it with your friends or colleagues! You can also share your thoughts here in the comment section!
Best of luck 🙂
