Working at a large tech company, we tend to approach microservice division as information authority division. If the data doesn't need to exist in the same dat

Working at a large tech company, we tend to approach microservice division as information authority division. If the data doesn't need to exist in the same database, put it in a new service with a separate database (or at least completely independent tables). Ideally there is no shared code between services (and there shouldn't need to be, because each service owns completely disparate data), so the only coupling is the API definitions. Each service is free to use whatever internal architecture they see fit as long as they honor the API definitions they provide to their dependent services. In the case outlined in the article, the fact that each microservice had similar enough concerns to all use some common libraries and the same database makes me doubt that this should ever have been built as microservices to begin with.