Service Granularity Principles and Decision Framework in Microservices

Problem Description
Service granularity division is one of the core challenges in microservices architecture design. It directly affects the system's maintainability, scalability, and team collaboration efficiency. The task requires mastering the scientific approach to delineating microservice boundaries, avoiding the extremes of being too coarse (leading to monolithic architecture issues) or too fine (introducing distributed system complexities), and establishing a systematic decision-making framework.

Solution Process

1. Understand the Core Trade-offs of Service Granularity

   • Disadvantages of Coarse Granularity: High functional coupling within the service, significant single point of failure risk, difficulty in technology stack iteration, and potential team collaboration bottlenecks.
   • Disadvantages of Fine Granularity: Increased network communication overhead, complex distributed transactions, soaring operational complexity, and heightened debugging difficulty.
   • Key Objective: Find a balance between clear business boundaries and system performance.

2. Apply Domain-Driven Design (DDD) to Define Boundaries

   • Step 1: Identify Bounded Contexts
     Analyze the business domain to divide the system into autonomous business units (e.g., Order Management, Inventory Management, Payment Service). Each context has clear responsibilities and a domain model, avoiding model contamination across contexts.
   • Step 2: Define Aggregate Roots
     Within a bounded context, determine aggregate roots based on units of consistency for data changes (e.g., the "Order" aggregate root includes order items and price calculation). A single aggregate root often corresponds to a candidate for the minimum granularity of a microservice.
   • Example: In an e-commerce system, the "Order Service" should be independent of the "User Service" because the logic for creating and querying orders changes at a different frequency than user authentication logic.

3. Adjust Granularity Based on Change Frequency and Team Structure

   • Application of Conway's Law: If teams are organized by business capability (e.g., payment team, logistics team), service boundaries should align with team responsibilities to reduce cross-team coordination costs.
   • Change Isolation Principle: Separate frequently changed functionality (e.g., promotion rules) from stable functions (e.g., address management) to avoid impacting unrelated modules during modifications.
   • Counterexample Warning: Merging "Product Query" and "Product Inventory Management" into one service could lead to frequent inventory deduction changes affecting query performance.

4. Validate Granularity Rationality with Technical Metrics

   • Performance Evaluation:
     • Monitor inter-service call latency: If calls between two services account for over 30% of total business latency, consider merging them.
     • Check data correlation: If Service A frequently requires joined queries with Service B's data (e.g., Order Service needs real-time user details), the boundary might be incorrectly drawn.
   • Operational Metrics:
     • Deployment independence: If a service needs deployment multiple times a week while its dependencies don't require updates, the granularity is likely reasonable.
     • Fault impact scope: A single service failure should not completely disrupt core business chains.

5. Use Decision Framework Tools to Aid Division

   • Four-Quadrant Evaluation Method:
     | High Cohesion, Low Coupling | Low Cohesion, High Coupling → Prioritize splitting
     | High Change Frequency | Low Change Frequency → Separate by change frequency
   • Service Dependency Graph Analysis:
     Visualize service dependencies using an architecture diagram. If circular dependencies or call chains deeper than 3 levels appear, boundaries need re-evaluation.

6. Iterative Optimization and Governance

   • Initial Strategy: Start with a slightly coarser granularity (e.g., divided by bounded contexts), then gradually split based on monitoring data after deployment.
   • Refactoring Signals: Trigger granularity refactoring when service code exceeds 100k lines, team commit conflicts become frequent, or API version iteration speeds differ significantly.
   • Evolution Example: Initially, a "User Service" might include personal information, points, and membership levels; later, as point calculation rules become complex, it can be split into an independent "Points Service".

Summary
Service granularity division is a dynamic balancing process that requires continuous adjustment based on business domain analysis, team capabilities, and technical metrics. The core principle is: through high-cohesion, low-coupling boundary design, ensure each service can be independently developed, deployed, and scaled.