There are two perspectives from which to approach evolving a microservice. One is from an architectural perspective and the other is from a database design perspective. We will discuss both perspectives one by one.
To start with, the best practice is to find out the feature with the lowest performance, or the feature with the least interaction. What would be even better is if you could choose a feature that does not directly interact with the user and is used to doing an offline job. Choose your service very wisely. It should not affect any other feature, and it should be completely independent of other services in terms of code, as well as the deployment cycle. For instance, we could have this service using the same database, but by using a completely independent deployment pipeline:
As in the preceding diagram, there are service layers that refer to lots of the feature's business logic. There could be a schedule jobs service or a...