Manu's Vault

Granularity of Architecture Characteristics

3 min readStatus:Seedling

Core Idea

Architecture characteristics don’t always apply uniformly across an entire system. They have granularity—some span the whole system while others apply only to specific components or services—and understanding this scope prevents overengineering and enables targeted optimization.

The Concept

Architecture characteristics have varying levels of granularity:

  • They can operate at different scopes within a system
  • Not every characteristic needs to apply to every part of an application
  • This fundamental insight challenges the assumption that all parts of a system must meet the same non-functional requirements

In traditional monolithic architectures, characteristics typically apply system-wide:

  • If any component requires high availability, the entire monolith must support high availability
  • If one module needs extreme performance, the whole application bears the cost of performance optimization
  • This “one size fits all” approach often leads to overengineering—applying expensive architectural solutions universally when they’re only needed locally

The concept of granularity becomes critical when choosing between monolithic and distributed architectures:

  • A distributed architecture enables different granularity by allowing each service or component to have its own characteristic profile
  • One microservice might optimize for performance and scalability
  • Another prioritizes security and auditability
  • Yet another focuses on deployability and experimentation

This architectural decision fundamentally shapes system structure:

  • Whether to treat characteristics uniformly or allow different granularities
  • The Architecture-Quantum concept formalizes this: it’s the smallest independently deployable unit with its own set of characteristics
  • In a monolith, the quantum is typically the entire application
  • In microservices, each service is its own quantum

However, enabling characteristic granularity comes with trade-offs:

  • Distributed systems introduce operational complexity, network latency, deployment orchestration challenges, and monitoring overhead
  • The architectural decision isn’t “which is better?” but rather “do different parts of our system genuinely need different characteristics enough to justify distribution’s costs?”

Why This Matters

Understanding characteristic granularity prevents two common architectural mistakes:

Over-distribution:

  • Adopting microservices or distributed architectures when all components actually need similar characteristics
  • This adds unnecessary complexity without delivering the benefit of targeted optimization

Under-distribution:

  • Forcing the entire system to meet the highest bar for every characteristic when only specific components require it
  • This increases costs and slows development across the board

By explicitly analyzing which characteristics apply where:

  • Architects can make informed decisions about system boundaries, deployment units, and architectural style
  • This granularity-aware thinking enables “right-sizing” architecture to actual needs
  • Rather than following trends or applying one-size-fits-all patterns

Sources

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.

Graph View

Backlinks