Microservice Granularity Optimizer

When to Use

You need to determine the right size for microservice boundaries, evaluate whether existing services should be split or merged, or select communication patterns (choreography vs orchestration) for inter-service coordination. The most common mistake in microservices is making services too small -- as Martin Fowler noted, "microservice" is a label, not a description. Typical situations:

• Splitting a monolith -- "we want to decompose into microservices, but how small should each service be?"
• Over-splitting diagnosis -- "we split too fine and now every request requires 5+ inter-service calls"
• Distributed transaction pain -- "we need atomic operations across services but SAGA is killing us"
• Communication design -- "should our services use choreography or orchestration?"
• Granularity evaluation -- "we have 30 microservices for a system that could be 8 -- did we over-decompose?"
• Merge vs split decision -- "these two services always change together and share data -- should we merge them?"

Before starting, verify:

• Has microservices been confirmed as the architecture style? If the user hasn't decided yet, consider using architecture-style-selector first.
• Are components identified? If not, use component-identifier to establish initial service candidates.
• If the user has existing microservices and is troubleshooting granularity, proceed directly.

Context & Input Gathering