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 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 components 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 it; if one module needs extreme performance, the whole application bears the optimization cost. This “one size fits all” approach leads to overengineering—applying expensive architectural solutions universally when they’re only needed locally.

Distributed architectures enable different granularity by allowing each service or component to have its own characteristic profile:

  • One microservice optimizes for performance and scalability
  • Another prioritizes security and auditability
  • Yet another focuses on deployability and experimentation

The architecture quantum concept formalizes this: the smallest independently deployable unit with its own characteristic set. In a monolith, the quantum is typically the entire application; in microservices, each service is its own quantum.

Enabling characteristic granularity carries trade-offs: distributed systems introduce operational complexity, network latency, deployment orchestration challenges, and monitoring overhead. The architectural question isn’t “which style is better?” but “do different parts of our system genuinely need different characteristics enough to justify distribution’s costs?”

Why It Matters

Understanding characteristic granularity prevents two common mistakes:

  • Over-distribution: adopting microservices when all components actually need similar characteristics, adding unnecessary complexity without delivering targeted optimization benefits
  • Under-distribution: forcing the entire system to meet the highest bar for every characteristic when only specific components require it, increasing costs and slowing development across the board

By explicitly analyzing which characteristics apply where, architects can make informed decisions about system boundaries and deployment units—right-sizing architecture to actual needs rather than following trends.

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.