Deciding When to Split or Join a Microservice
One of the valuable chapters in “Software Architecture: The Hard Parts” answers this difficult question by rationally justifying the “Wise Why’s” behind when a decision to split or join a microservice should or should not be made
Chapter 7 of the Book Software Architecture: The Hard Parts uses the term “Granularity Disintegrators” to refer to reasons to split a service and uses the name “Granularity Integrators” to indicate the reasons to keep a service as a single unit (or join several services if needed).
I’ll try here to summarize the decision factors discussed in this chapter briefly and add a twist to the advice by first considering your decision based on Integrators (keeping as a single unit) rather than Disintegrators simply because it’s difficult to undo the work after a microservice gets split.
Let’s start with Reasons To Keep (or Join) a Single Service.
Reasons To Join (or Keep) as a Single Service
Join Reason #1: Keeping Database Transactions. If having an ACID transaction is necessary from the business perspective, then keeping the service as a single unit is preferred…
