In my mind, there are a small number of legitimate reasons to split out a new back-end service in an existing architecture. Here they are:
- The new functionality would be easier to build using a different tech stack
- The scaling requirements of the new functionality are different than the current system
- The new functionality requires different access controls than the rest of the system
- A different deployment method or frequency would be better for the new functionality.
Or, stated in pain points:
- I can’t build this in the language we’re using
- This thing won’t be performant enough if I add it to our current system
- No way in heck am I giving our current system unfettered access to X
- I have to deploy 137 times a day and our current CI workflow takes an hour
There are a lot of hard things about building distributed systems. These problems include: eventual consistency, serialization overhead, network latency, segmentation tolerance, distributed consensus, service discovery, schema synchronization, ordered changes, inter-service authentication, service-to-service encryption, request loops, event loops, event ordering, lions, tigers, bears, sharknados, and most terrifyingly XML if you do it wrong. New services should not be split out lightly – often the pain of solving all the issues of distributed systems is worse than the pain of working in a crufty old codebase. Introduce network boundaries only with great thought and consideration.