Style Selection by Architectural Characteristics
What This Concept Is
Architectural characteristics (a.k.a. non-functional requirements or quality attributes from M01) are the primary input to style selection. You do not choose a style by taste; you choose it by the characteristics the system must support, stated measurably.
The loop:
Richards and Ford give a ratings table comparing styles across:
| Characteristic | Layered | Pipeline | Modular Monolith | Service-Based | Event-Driven | Space-Based | Microservices |
|---|---|---|---|---|---|---|---|
| Overall cost | low | low | low-medium | medium | medium-high | high | high |
| Simplicity | high | very high | medium | medium | low | low | low |
| Deployability | low | low | medium | high | medium | medium | very high |
| Elasticity | low | low | low | medium | high | very high | high |
| Evolutionary | low | medium | high | high | high | medium | very high |
| Fault tolerance | low | low | low | medium | high | medium | high |
| Performance | medium | low-medium | high | medium | medium | very high | low-medium |
| Scalability | low | low | medium | medium | high | very high | high |
| Testability | high | high | high | medium | low | low | low |
(Exact ratings can vary by source; use these as starting points, not gospel.)
The three use-case filters
- Is it request-oriented or transform-oriented? Request -> layered, service-based, microservices. Transform -> pipeline.
- Is it synchronous or async-by-nature? Sync -> layered, service-based, microservices. Async -> event-driven.
- Does it need extreme elasticity on a hot slice? Yes -> space-based. No -> anything else.
These three filters narrow the field fast.
Why It Matters Here
This is the concept that makes the preceding twelve concepts useful. Knowing what every style is matters only if you can use the characteristics in front of you to choose. Skipping this step is the single most common mistake in style selection -- and every style in this module has the ratings already laid out in Richards and Ford specifically so you do not have to guess.
Concrete Example
Scenario: build a backend for a live-auction platform.
Characteristics (ranked by the team):
- Performance -- bid responses must be <100ms p99
- Elasticity -- 50x traffic during a headline auction
- Fault tolerance -- a degraded bidder experience is fine; an outage during auction end is catastrophic
- Deployability -- weekly feature shipping
- Testability -- wanted but accepted lower
Shortlist from the ratings table:
- Microservices scores high on deployability and elasticity, medium-low on performance due to network. Viable if network cost is manageable.
- Event-driven scores high on elasticity and fault tolerance, low on sync-request performance.
- Space-based scores very high on performance, scalability, elasticity. Strong candidate for the bidding core.
Decision:
- Space-based architecture for the bidding core (the processing unit is "auction"; in-memory bid book; async flush to DB).
- Event-driven for the periphery (fulfillment after win, notifications, analytics).
- Modular monolith for supporting admin tools.
This is a hybrid architecture (see Concept 15). Most real systems land here, not on a single style.
Second example: ERP-style internal tool
Characteristics:
- Evolutionary -- business rules change constantly
- Testability -- auditors require
- Simplicity -- small team, no distributed-systems experience
- Low performance requirements -- internal, 20 users
Shortlist:
- Layered: high testability, high simplicity, low deployability -- but they do not need deployability.
- Modular monolith: high evolutionary, high testability, medium simplicity -- good.
- Microservices: contradicts most of the ranked characteristics.
Decision: modular monolith. Microservices would have been a clear mistake driven by "it's modern."
Common Confusion / Misconception
"The ratings table is the decision." It is the input to the decision. Ratings are averages from many systems; your system has its own constraints (budget, team experience, compliance). Use ratings to shortlist, then use scenarios and tradeoffs to choose.
"Pick the style with the most 'highs'." Different systems need different things. A system that needs high simplicity and does not need high elasticity should not be scored "most highs across the board." Weight by your ranked characteristics.
"Performance is always the top priority." Performance is usually not the top priority of a typical line-of-business system. Time-to-market, evolvability, and testability typically rank higher. Pick what your business actually needs.
"If characteristics conflict, pick the strongest style." They often conflict. That is the entire point of tradeoff analysis (M01). Pick the style that best supports the most important characteristics, and name which ones you are giving up.
How To Use It
A short decision-document format:
# Style selection for [System]
## Characteristics (ranked)
1. ...
2. ...
3. ...
## Shortlist
- Style A -- pro: ..., con: ...
- Style B -- pro: ..., con: ...
## Decision
Style A, because ...
## Consequences
- gain: ..., ..., ...
- lose: ..., ..., ...
## Alternatives we rejected
- Style B -- because ...
- Style C -- because ...
This is functionally an ADR (M05). You should produce one for every serious style decision and version-control it.
Check Yourself
- Why is performance not always the top-ranked characteristic? Name two systems where simplicity dominates.
- A team says "microservices because evolutionary." Is that a defensible argument? What is the cheaper answer?
- Layered and pipeline both rate low on elasticity. Why, physically? (Hint: what does "scaling" mean for each?)
Mini Drill or Application
Pick three systems (or use: (a) a fraud-detection service, (b) an internal timesheet, (c) a live-streaming ingest pipeline). For each, 10 minutes:
- List the top 3 characteristics in order of priority.
- Shortlist 2-3 candidate styles from the ratings table.
- Pick one and write a 2-sentence ADR verdict.
- Name the characteristic you gave up.