Let’s say we have a microservice-based architecture, that has been up and running for several months, now business team come and asked about adding a new feature. from this point, it’s on the development team to decide and answer this dilemma; whether to add the feature to an existing microservice or create a new microservice. There is no one-size-fits-all rule, but we can say most probably these rules that we are going to check, in most scenarios would work.
“Create a New or Extend a Preexisting Service?”, That is the question…
Here are some signs that the functionality could be better suited for a new service:
1- If a service relies on multiple others, it may have too many responsibilities. Creating a new service and migrating some functionality can help. Centralizing extensive logic in one service can lead to complexity, so separating the logic is advisable.
2- Multiple teams managing a service without clear ownership, can impede the agility of a microservice architecture. Dividing the service and its responsibilities should be considered. While this may not be the sole reason to create a new service, it can be a strong argument when combined with other factors.
3- When new functionality demands a different technology stack, integrating it into an existing service can be problematic. Using two separate services with distinct technology stacks simplifies maintenance, release, and deployment processes.
4- If new functionality has a unique usage pattern and needs independent scaling, it’s a good reason to create a separate service. This is particularly useful when the new functionality has significantly higher usage or experiences seasonal peaks, like Fridays, enabling efficient, isolated scaling.
Here are some signs that the functionality could be better suited for an existing service:
1 – The new functionality’s conceptual domain is closely linked to an existing service. For instance, consider orders and order lines, which are closely related in many systems. It’s best to keep related domains together when their changes are correlated for more efficient coding.
2 – When you consider the potential ripple effects of sharing a database, you’ll find that it not only affects development but can also have profound implications for your system’s long-term scalability and adaptability. By embracing alternatives like event-driven architecture or service enhancements, you pave the way for a more agile, future-proof software infrastructure that can readily evolve with your organization’s changing needs, ultimately ensuring a smoother and more sustainable development journey.
3 – The anemic domain model is a common antipattern in microservices. These services lack domain logic and primarily serve as database interfaces. Adding more functionality and domain value is essential when domain logic is lacking, although not all services require heavy domain logic; some perform more basic or infrastructural tasks.
Final Thought
In conclusion, the question of “Create a New or Extend a Preexisting Service?” is a nuanced one, and there’s no one-size-fits-all answer. Instead, it hinges on careful evaluation of various factors, from service responsibilities and technology stack to usage patterns and domain logic. By thoughtfully weighing these considerations, you can steer your microservices architecture toward a more resilient, agile, and future-ready future. In the end, your decision should align with your organization’s unique needs, setting the stage for successful and sustainable software development endeavors.
Reference
I just read Hugo Filipe Oliveira Rocha’s great book, “Practical Event-Driven Microservices Architecture” It mainly discusses challenges in event-driven systems. I thought it would be useful to share some ideas with you all. I hope you can read the whole book and learn as much as possible from it, I will also write a review of this book soon, If you are interested in this kind of material you would also like to read my article about A Short Review of “Building Evolutionary Architectures” book.
Cheers and stay tuned . . . Matt Ghafouri
