Chapter 7: Scope of Architectural Characteristics
fsa architectural-characteristics quantum scope
Status: Notes complete
Overview
Architectural characteristics (like scalability, availability, and performance) do not apply uniformly across an entire system. Chapter 7 introduces the concept of architectural quantum as the proper unit of scope for measuring and applying architectural characteristics. Understanding quantum boundaries is essential for making rational decisions about architecture style and decomposition strategy.
The Problem with System-Wide Characteristics
Early architectural thinking applied characteristics globally: “the system must be highly available” or “the system must be scalable.” This is imprecise and often leads to over-engineering or misaligned decisions. Different parts of a system often have radically different operational requirements.
Example: In a retail application, the product catalog needs high availability and read scalability, but the order fulfillment pipeline needs high consistency and auditability — not the same characteristics at all.
The solution is to scope architectural characteristics to the smallest meaningful unit of the architecture.
Architectural Quantum — Definition
An architectural quantum is:
An independently deployable artifact with high functional cohesion, high static coupling, and synchronous dynamic coupling.
This is the core definition introduced by Richards & Ford. Each part of the definition carries weight:
1. Independently Deployable
The quantum can be deployed, scaled, and operated independently of other parts of the system. It has its own deployment pipeline and runtime boundary. This maps closely to the concept of a deployable unit — a JAR, a container image, a serverless function group, etc.
2. High Functional Cohesion
The quantum contains code that serves a unified business purpose. It is not a technical slice (all the DAOs, all the controllers) but a domain slice (all the code for “auction bidding”). This aligns with the Single Responsibility Principle at the architectural level.
3. High Static Coupling
Static coupling refers to compile-time dependencies — shared libraries, shared databases, shared schemas, shared data models. Elements with high static coupling are tightly bound at build/deploy time. If two services share a database schema, they have high static coupling and may belong to the same quantum, even if they are separately deployed.
4. Synchronous Dynamic Coupling
Dynamic coupling refers to runtime communication. Synchronous dynamic coupling means that when service A calls service B synchronously (REST, gRPC, etc.), both must be available at the same time. This effectively merges their operational characteristics — the availability and scalability of both must be considered together. Two services that communicate synchronously at runtime are part of the same quantum from an operational standpoint.
Static vs. Dynamic Coupling
| Coupling Type | When It Occurs | Examples | Implication |
|---|---|---|---|
| Static | Compile/build time | Shared libraries, shared DB schema, shared data model | Must be deployed together or manage versioning |
| Dynamic (Synchronous) | Runtime, blocking | REST calls, gRPC, SOAP | Both services must be available simultaneously; characteristics merge |
| Dynamic (Asynchronous) | Runtime, non-blocking | Message queues, event streams | Services can have independent operational characteristics |
Key insight: Asynchronous communication is a quantum boundary — it allows two services to operate independently in terms of availability and scalability. Synchronous communication merges quanta.
How Synchronous Communication Merges Quanta
Consider three services: A → B → C where all calls are synchronous.
- If B is unavailable, A’s request fails. If C is unavailable, B (and therefore A) fails.
- The availability of the composite system is: Availability(A) × Availability(B) × Availability(C).
- For 99.9% availability on each: 0.999 × 0.999 × 0.999 ≈ 99.7%.
- All three services must scale together to handle peak load.
- From an architectural characteristics perspective, A, B, and C form one quantum.
If instead A → (queue) → B → (queue) → C:
- B and C can be down for brief periods without A failing.
- Each can scale independently.
- Three separate quanta.
This is the foundational argument for asynchronous communication in microservices.
Single vs. Multi-Quantum Architectures
Single-Quantum Architecture
A system with a single architectural quantum has one set of operational characteristics that apply to the entire system. The canonical example is a monolithic architecture.
- All components share the same deployment unit.
- All components share the same database.
- All components must scale together.
- The architecture has uniform availability, scalability, and performance characteristics.
- Simple to reason about but limits the ability to optimize individual parts.
When appropriate: When the business domain has uniform operational requirements, when team size is small, or when the system is in early stages.
Multi-Quantum Architecture
A system with multiple architectural quanta allows different parts of the system to have different operational characteristics. The canonical example is microservices.
- Each service (quantum) can be deployed independently.
- Each service can have its own database.
- Each service can be scaled independently.
- Different services can have different availability SLAs, different consistency models, different technology stacks.
When appropriate: When different parts of the system have genuinely different operational requirements, when team autonomy and independent deployment velocity are priorities.
Scoping and Architectural Style
The number of quanta in a system is a direct consequence of architectural style choices:
| Architecture Style | Typical Quantum Count | Notes |
|---|---|---|
| Monolith (Layered) | 1 | All code in one deployable unit |
| Modular Monolith | 1 (logical modules) | Still one deployable; modules are logical, not runtime boundaries |
| Service-Oriented Architecture (SOA) | Few (2–10) | Coarse-grained services, often with shared ESB |
| Microservices | N (many) | One quantum per service, each independently deployable |
| Event-Driven (with async messaging) | N | Async boundaries enable quantum independence |
| Serverless | N | Each function group is potentially its own quantum |
Practical implication: Before selecting an architecture style, catalog the distinct operational characteristic profiles in the system. The number of distinct profiles suggests the minimum number of quanta needed.
Scoping Architectural Characteristics in Practice
Step 1: Identify Distinct Operational Profiles
Walk through the business capabilities of the system and ask: does this capability require different scalability, availability, consistency, or performance than other capabilities? Group capabilities with similar profiles.
Step 2: Map Profiles to Quanta
Each distinct profile becomes a candidate quantum. Verify that:
- The candidate quantum has a well-defined deployment boundary.
- Internal communication can be synchronous.
- Cross-quantum communication should be asynchronous where possible.
Step 3: Check Coupling
Review static coupling (shared databases, shared libraries) and dynamic coupling (synchronous calls) across proposed quantum boundaries. If two proposed quanta have high static coupling or mandatory synchronous communication, consider merging them.
Step 4: Validate with “-ilities”
For each quantum, define the target architectural characteristics explicitly: availability %, scalability requirements, performance SLA, consistency model. These become the measurable design goals for that quantum.
Kata: Going Green (Sustainability Platform)
Richards & Ford use the “Going Green” kata to illustrate quantum scoping. The system is a sustainability tracking platform that helps organizations monitor and report on environmental metrics.
Business Capabilities Identified
- Data Ingestion: Collects sensor data and manual inputs. High throughput, eventual consistency acceptable. Needs to remain operational even when other parts are down.
- Analytics Processing: Computes sustainability scores, trend analysis. Batch-oriented, computationally intensive, can tolerate latency.
- Reporting: Generates compliance reports, dashboards. Needs high availability for end-users, read-heavy.
- Alerting: Sends notifications when thresholds are exceeded. Low latency, high availability.
- User Management: Authentication, authorization. Moderate availability, low traffic.
Quantum Analysis
| Capability | Availability Need | Scalability | Consistency | Quantum |
|---|---|---|---|---|
| Data Ingestion | High (always collecting) | High (variable input) | Eventual | Quantum 1 |
| Analytics Processing | Moderate (batch) | High (compute) | Eventual | Quantum 2 |
| Reporting | High (user-facing) | Moderate | Read-eventual | Quantum 3 |
| Alerting | High | Low-moderate | Strong | Quantum 4 |
| User Management | Moderate | Low | Strong | Quantum 5 |
Key Design Decisions
- Data Ingestion and Analytics are decoupled via an async message stream — they can scale and fail independently.
- Reporting reads from a denormalized store populated by Analytics (event-driven, async).
- Alerting subscribes to the same analytics stream but operates independently.
- Five quanta, each with independently tunable operational characteristics.
Lesson
The Going Green kata demonstrates that even a “simple” system can benefit from multi-quantum thinking when business capabilities have genuinely different operational profiles. The architecture is not built around technology; it is built around operational requirement profiles.
Scoping in the Cloud
Cloud environments amplify the importance of quantum thinking because cloud services provide fine-grained control over deployment, scaling, and availability — but only if the architecture is decomposed appropriately.
Cloud-Native Quantum Boundaries
- Containers / Kubernetes: Each deployment (Deployment resource) is a natural quantum boundary. Pods can scale independently; services communicate via synchronous HTTP or async messaging.
- Serverless Functions: Each function or function group is a quantum. Cold start behavior, concurrency limits, and timeout constraints differ per function.
- Managed Data Services: Choosing separate data stores per quantum (RDS instance per service, DynamoDB table per service) enforces static coupling boundaries.
Cloud Anti-pattern: Shared Database in Multi-Quantum Design
Deploying microservices (multiple intended quanta) but routing all of them to a single relational database instance collapses the quanta back into one. The shared database becomes the static coupling point that defeats the multi-quantum intent. The database becomes the bottleneck for scalability and the failure point for availability.
Cloud Pattern: Event Bus as Quantum Boundary
Using an event bus (SNS/SQS on AWS, Pub/Sub on GCP, Service Bus on Azure) between services creates explicit async boundaries that allow quanta to be independently operational. The event bus absorbs load variations and decouples availability requirements.
Elasticity and Quantum-Specific Scaling Policies
In a properly scoped multi-quantum architecture, each quantum can have its own auto-scaling policy. The ingestion quantum scales on message backlog; the reporting quantum scales on HTTP request rate; the analytics quantum scales on CPU utilization. This is impossible in a single-quantum architecture.
Trade-offs and Decision Framework
| Option | Pros | Cons | When to Choose |
|---|---|---|---|
| Single Quantum (Monolith) | Simple deployment, easy transactions, low operational overhead | Cannot tune characteristics independently, all-or-nothing scaling, single point of failure | Early stage, uniform operational requirements, small team |
| Multi-Quantum (Microservices) | Independent scaling, independent failure domains, technology flexibility | High operational complexity, distributed systems challenges, data consistency difficulties | Distinct operational profiles, large teams, independent deployment cadence required |
| Hybrid (Modular Monolith + extracted services) | Balance of simplicity and flexibility, extract only what needs different characteristics | Requires discipline to maintain modular boundaries, partial complexity | Most medium-sized systems; extract only the quanta that genuinely need it |
| Async-first communication | Natural quantum boundaries, resilience, decoupling | Eventual consistency complexity, harder to debug, message ordering challenges | Default for cross-quantum communication |
| Sync-first communication | Simple to implement, easy to reason about request/response | Merges quanta, creates availability coupling, harder to scale independently | Only within a quantum |
Common Antipatterns
Distributed Monolith: Deploying multiple services but coupling them tightly via synchronous calls and a shared database. The operational overhead of microservices with none of the benefits — one quantum wearing many clothes.
Characteristics Inflation: Declaring that every part of the system needs five-nines availability and horizontal scalability, regardless of actual business requirements. This inflates cost and complexity without proportional benefit.
Quantum Sprawl: Over-decomposing to the point where the operational overhead of managing hundreds of tiny quanta exceeds the benefit. Every network call, every deployment pipeline, every monitoring dashboard adds overhead.
Synchronous Chain Anti-pattern: Building a deep chain of synchronous service calls (A → B → C → D → E) that effectively merges all services into one quantum with compounded failure probability.
Ignoring Static Coupling: Declaring multi-quantum architecture while all services share a single database schema. The schema becomes the real coupling point; independent deployment is theater.
Key Takeaways
- Architectural Quantum: The proper unit of scope for architectural characteristics — an independently deployable artifact with high functional cohesion, high static coupling, and synchronous dynamic coupling.
- Static Coupling: Compile-time dependencies (shared libraries, shared databases) that bind components together at build/deploy time.
- Dynamic Coupling: Runtime dependencies; synchronous dynamic coupling merges quanta, while asynchronous coupling creates quantum boundaries.
- Synchronous Merges Quanta: When two services communicate synchronously, their availability, scalability, and performance characteristics become interdependent — they form one quantum.
- Monolith = One Quantum: A traditional monolithic architecture is by definition a single-quantum system with uniform architectural characteristics across all components.
- Microservices = N Quanta: Each microservice is (ideally) its own quantum with independently tunable operational characteristics.
- Profile Before Decomposing: Identify distinct operational characteristic profiles before choosing architecture style; the number of profiles suggests the appropriate number of quanta.
- Async as Quantum Boundary: Asynchronous messaging between services is the primary mechanism for creating independent quantum boundaries in distributed systems.
- Cloud Amplifies Quantum Value: Cloud environments provide the infrastructure to operationalize per-quantum scaling, availability, and monitoring — but only if the architecture is properly decomposed.
- Shared Database Collapses Quanta: A shared database in a multi-service architecture is the most common way to inadvertently collapse intended quanta back into a single operational unit.
Related Resources
- Chapter 4: Architectural Characteristics Defined (what characteristics are)
- Chapter 5: Identifying Architectural Characteristics (how to elicit them)
- Chapter 6: Measuring and Governing Architectural Characteristics (fitness functions)
- Chapter 8: Component-Based Thinking (how quanta map to components)
- Chapter 9: Foundations of Architecture Styles (how style determines quantum count)
Last Updated: 2026-05-29