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

Photo by Aveedibya Dey on Unsplash

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…