Granularity Disintegrators

Core Idea

Granularity disintegrators are architectural forces that drive decomposition of larger services into smaller, focused units.

Definition

Granularity disintegrators are architectural forces that drive decomposition of larger services into smaller, focused units. These forces represent quality attributes, operational concerns, or design constraints that benefit from service separation. When a disintegrator force is strong, it creates pressure to break apart monolithic components or split existing services.

Service sizing isn’t determined by universal rules but by analyzing competing forces within each architectural context. Disintegrators oppose granularity integrators—forces favoring larger, more integrated services.

Key Characteristics

• Service scope and function: Most fundamental disintegrator—different business capabilities or bounded contexts naturally push toward separate services
• Code volatility: Components changing at different rates benefit from separation; frequently changing code isolates for easier testing and deployment
• Scalability and throughput: Different scaling requirements drive separation for independent scaling without scaling the entire monolith
• Fault tolerance: Isolating failure-prone components prevents cascading failures and protects critical functionality
• Security requirements: Different security postures (public-facing vs. internal, PII vs. non-sensitive) enable targeted controls
• Extensibility needs: Frequently extended components isolate to prevent complexity from affecting core stability
• Team autonomy: Different teams owning different system parts create natural service boundaries (Conway’s Law)

Examples

• E-commerce: Splitting product catalog (stable, read-heavy) from inventory (volatile, write-heavy) addresses different volatility and scalability
• Payment processing: Isolating payment services for enhanced security, compliance, and fault isolation
• Reporting: Separating analytical workloads prevents long-running queries from impacting user-facing performance
• Authentication: Extracting auth into dedicated service enables reuse and centralized security

Why It Matters

Disintegrators enable evidence-based decomposition decisions rather than arbitrary rules like “services should be 100 lines of code.” This framework evaluates when service separation creates architectural benefits versus unnecessary complexity.

The analysis prevents over-decomposition (excessive inter-service overhead) and under-decomposition (monolithic services hard to scale and maintain). Different contexts prioritize different disintegrators—startups emphasize code volatility and team autonomy, enterprises prioritize scalability and fault tolerance.

Disintegrators must balance against integrators—forces favoring larger services (ACID transactions, shared data, workflow coordination). Right granularity emerges from analyzing competing forces in each architectural context.

Related Concepts

• Service-Granularity - The broader concept of determining service size and scope
• Coupling - Service separation reduces coupling between components
• Scalability - A primary disintegrator driving service decomposition
• Fault-Tolerance - Isolation through service boundaries improves system resilience
• Modularity - The fundamental principle underlying service decomposition
• Bounded-Context - DDD concept that naturally defines service boundaries
• Ford-Richards-Sadalage-Dehghani-2022-Software-Architecture-The-Hard-Parts - Primary source introducing the disintegrators framework

Sources

• Ford, Neal, Mark Richards, Pramod Sadalage, and Zhamak Dehghani (2022). Software Architecture: The Hard Parts. O’Reilly Media. ISBN: 9781492086895. Chapter 7.

  • https://www.thoughtworks.com/content/dam/thoughtworks/documents/books/bk_software_architecture_hard_parts_ch7_en.pdf

• Munasinghe, Sidath (2024). “Right-Sizing Microservices: Harnessing Integrators and Disintegrators.” Medium.

  • https://medium.com/@sidathasiri/right-sizing-microservices-harnessing-integrators-and-disintegrators-for-scalable-architecture-50f96e28c812

• Klotz, Andrew. “Service Granularity, Disintegrators.”

  • https://klotzandrew.com/blog/service_granularity_disintegrators/

• Abgaz, Yalemisew, et al. (2026). “From Monolith to Microservices: A Comparative Evaluation of Decomposition Frameworks.” arXiv arXiv:2601.23141.

  • https://arxiv.org/abs/2601.23141

• Rotem-Gal-Oz, Arnon (2025). “Microservices Granularity Tradeoffs.” Medium.

  • https://medium.com/@arnonrgo/microservices-granularity-tradeoffs-171594fad8ca

• Richardson, Chris (2023). “Thoughts about Service Granularity.” Microservices.io.

  • https://microservices.io/post/architecture/2023/09/21/about-service-granularity.html

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.