Chapter 19: Choosing the Appropriate Architecture Style
fsa choosing-architecture-style decision-making
Status: Notes complete
Overview
Chapter 19 addresses the central practical challenge every architect faces: given a specific context, which architecture style should you choose? The chapter rejects the idea that any single style is universally superior and instead provides a structured decision framework based on domain characteristics, operational requirements, team structure, and business constraints. It illustrates the framework through two detailed case studies — a local sandwich ordering system (monolith territory) and an online auction platform (distributed territory) — demonstrating that the right answer depends entirely on context, not trend.
The Core Challenge: No Universal “Best” Architecture
There is no universally correct architecture style. Every style involves trade-offs, and the architect’s job is to match the trade-off profile of a style to the specific constraints and goals of the system being built. Choosing a style because it is fashionable, or because it worked for a previous project, is one of the most common sources of architectural failure.
The key insight: architecture styles solve specific problems. Microservices solve the problem of independent deployability and extreme scalability at the cost of operational complexity. A layered monolith solves the problem of team simplicity and low cost at the expense of deployment granularity. An architect who understands why each style exists can reason about whether those problems are the ones their system actually has.
Why “Best Practice” Is a Trap
The phrase “best practice” implies context-independence — that a practice is best regardless of circumstances. In architecture, this is almost never true. A practice that is best for a 500-engineer platform team at a hyper-growth startup is almost certainly not best for a 5-engineer team building an internal tool. Architects must replace “what is best practice?” with “what are my constraints, and which style’s trade-offs fit them best?”
Shifting Fashion in Architecture
The Technology Waves
Architecture styles rise and fall in popularity in waves that track the dominant problems of their era:
| Era | Dominant Style | Problem It Solved |
|---|---|---|
| 1990s–2000s | Layered (N-tier) | Organized previously unstructured codebases; matched team skill silos |
| Early 2000s | SOA (Service-Oriented) | Enterprise integration; reuse across business units |
| 2010s | Microservices | Independent deployability; team autonomy at scale |
| Late 2010s–2020s | Event-Driven | Real-time responsiveness; decoupled scalability |
| 2020s | Modular Monolith | Correction of microservices over-application; operational simplicity |
Each wave emerged because the previous dominant style created new problems at scale. SOA’s heavy ESB infrastructure became a bottleneck. Microservices’ operational complexity became unmanageable for smaller teams. The modular monolith re-emerged as architects recognized that many systems had adopted microservices not because they needed independent deployability, but because microservices were fashionable.
Why Following Fashion Is Dangerous
Architectural fashion following causes teams to adopt a style’s costs without gaining its benefits, because the problems the style solves are not the problems the team has.
Symptoms of fashion-following:
- “We’re doing microservices because that’s what Netflix does”
- Adopting a style at greenfield without asking what characteristics are actually required
- Rewriting a working monolith into microservices to modernize it without evidence the monolith is the bottleneck
The correct diagnostic question: What problems does this style solve, and do we have those problems?
Decision Criteria for Style Selection
The following factors, evaluated together, point toward the appropriate architecture style. No single factor is determinative — architects weigh the combination.
1. Domain Partitioning vs. Technical Partitioning
- Technical partitioning (layered): suits small teams, simple domains, skill-based team organization, low coupling between business domains
- Domain partitioning (modular monolith, microservices, service-based): suits larger teams, complex domains with clear bounded contexts, need for independent evolution per domain
2. Number of Architecture Quanta
An architecture quantum is the smallest deployable unit with high functional cohesion and its own architectural characteristics. The number of quanta required shapes the style choice:
| Quanta Count | Implication |
|---|---|
| 1 | Monolithic styles are appropriate |
| 2–4 | Service-based or modular monolith |
| Many (5+) | Microservices or event-driven |
3. Deployment Granularity
- Coarse-grained deployment (deploy everything together): layered monolith, modular monolith, microkernel
- Fine-grained deployment (deploy individual services independently): microservices, service-based, event-driven
If independent deployment of individual capabilities is a hard requirement, monolithic styles are eliminated.
4. Workflow Patterns
- Orchestration-heavy workflows (one coordinator controls a multi-step process): service-based, microservices with an orchestrator
- Choreography-heavy workflows (services react to events autonomously): event-driven architecture
- Complex bidirectional workflows favor orchestration; high-throughput, loosely coupled event processing favors choreography
5. Key Architectural Characteristics Required
The required fitness functions (agility, scalability, reliability, etc.) filter the candidate styles. Each style has characteristic strengths:
- Agility/Deployability: microservices, modular monolith
- Scalability: microservices, event-driven, space-based
- Simplicity/Cost: layered monolith, pipeline
- Reliability/Fault Tolerance: event-driven, space-based
- Testability: modular monolith, pipeline
- Domain isolation: service-based, microservices, modular monolith
6. Team Size and Distribution
| Team Size | Recommended Direction |
|---|---|
| < 10 engineers | Monolithic (layered, modular monolith, microkernel) |
| 10–50 engineers | Service-based, modular monolith |
| 50+ engineers, multiple teams | Microservices, event-driven |
Distributed systems require distributed teams — the operational overhead of microservices is only justified when teams are large enough that the coordination cost of a monolith exceeds the operational cost of distribution.
Conway’s Law is a real constraint: the system’s structure will mirror the team’s communication structure. Architects must either design for the team they have or use the Inverse Conway Maneuver to restructure teams to match the desired architecture.
7. Budget Constraints
| Style | Relative Cost |
|---|---|
| Layered Monolith | Low |
| Pipeline | Low |
| Microkernel | Low–Medium |
| Modular Monolith | Low–Medium |
| Service-Based | Medium |
| Event-Driven | Medium–High |
| Microservices | High |
| Space-Based | Very High |
Microservices require investment in container orchestration, service discovery, distributed tracing, API gateways, and multiple independent deployment pipelines. This overhead is only cost-effective when the scale or independence benefits materialize.
8. Migration vs. Greenfield
- Greenfield: full freedom to choose any style; decision is driven purely by requirements and constraints
- Migration: the existing system’s structure constrains options; strangler fig pattern is often used to incrementally migrate from a legacy monolith; full rewrites are high-risk
For migrations, a modular monolith is often the intermediate step — decompose the monolith into modules first, then optionally extract services if needed.
Monolith Case Study: Silicon Sandwiches
Problem Description
Silicon Sandwiches is a local sandwich shop chain wanting to launch an online ordering system. Key facts:
- Small regional operation — not expecting massive scale
- Customizable sandwiches with a complex menu (toppings, sizes, bread types, sauces)
- Needs to support online orders, loyalty program, third-party delivery integration
- Small development team (< 10 engineers)
- Budget is limited — this is a small business
Identifying Required Characteristics
| Characteristic | Priority | Reasoning |
|---|---|---|
| Customizability (extensibility) | High | Complex menu configuration; frequent menu changes |
| Simplicity | High | Small team, limited budget |
| Testability | Medium | Menu logic must be correct |
| Scalability | Low | Regional only, modest traffic |
| Agility | Medium | Menu changes need to be fast |
| Cost | High | Small business budget |
Evaluating Monolithic Candidates
Layered Architecture:
- Simple, well-understood, cheap to build
- But: poor extensibility — adding new menu items or discount plugins requires changes throughout all layers
- Menu customization logic spread across presentation, domain, and data layers — tight coupling
Modular Monolith:
- Organizes code into domain modules (Menu, Orders, Loyalty, Delivery Integration)
- Single deployment unit — low operational cost
- Good testability per module
- Supports extensibility within each module
- Fits small team well
- Weakness: cannot deploy modules independently
Microkernel:
- Core system handles order processing; plugins extend menu behavior, discount rules, and third-party integrations
- Excellent extensibility — each customization is a plugin
- Fits the “complex configurable menu + loyalty + delivery partner” structure well
- Low operational complexity (still a monolith)
- Testability of plugins is high
Conclusion
Modular Monolith or Microkernel wins for Silicon Sandwiches.
- Microkernel is the best fit if the primary driver is menu extensibility and third-party integration variation (different delivery partners as plugins)
- Modular Monolith is the best fit if the primary driver is domain organization and team structure
Both are vastly superior to a layered architecture because the domain’s complexity and extensibility requirements are poorly served by technical partitioning. Microservices would be catastrophically over-engineered — the scalability, independent deployment, and team-autonomy benefits of microservices provide zero value at this scale, while imposing all the operational costs.
Distributed Case Study: Going, Going, Gone
Problem Description
Going, Going, Gone is an online auction platform with the following characteristics:
- Internet-scale bidding — potentially millions of concurrent users during popular auctions
- Real-time requirements — bids must be processed and reflected immediately; stale data causes incorrect auction outcomes
- High availability — the system cannot go down during an active auction
- Complex workflows — item listing, bidding, auction closing, payment, notifications, fraud detection
- Multiple independent domains — Bidding, Listings, Payments, Notifications, User Management
- Large engineering organization expected to grow
Identifying Required Characteristics
| Characteristic | Priority | Reasoning |
|---|---|---|
| Scalability | Critical | Internet-scale concurrent bidding |
| Elasticity | Critical | Traffic spikes at auction close |
| Availability | Critical | Downtime = lost bids = legal/financial liability |
| Real-time responsiveness | High | Bid accepted/rejected must be near-instantaneous |
| Agility | High | Business model evolves; auctions, listings rules change |
| Data integrity | High | Winning bid must be accurately recorded |
| Fault tolerance | High | Individual service failure must not collapse auctions |
Evaluating Distributed Candidates
Service-Based Architecture: Could work for domain separation, but a centralized database becomes a scalability bottleneck at auction-close traffic spikes. Not elastic enough.
Event-Driven Architecture:
- Bids published as events — bid processors consume and validate
- Auction close triggers a cascade of events (winner notification, payment initiation, inventory update)
- Highly scalable via partitioned event streams (e.g., Kafka topics per auction)
- Naturally elastic — add more bid-processing consumers under load
- Decoupled — Notifications service reacts to auction-close events without bidding service knowing it exists
- Fault tolerant — individual consumer failure doesn’t stop the stream
Microservices:
- Maximum deployment independence
- Each service (Bidding, Payments, Listings, Notifications) evolves independently
- High operational complexity — acceptable given scale and team size
- Combined with event-driven communication for the real-time bidding flow
Conclusion
Event-Driven Architecture combined with Microservices is the right fit for Going, Going, Gone.
- The core bidding flow (submit bid → validate → record → notify) maps naturally to an event-driven pipeline — high throughput, real-time, elastic
- Domain services (Listings, Payments, User Management) operate as microservices with synchronous APIs for non-real-time operations
- The combination captures the scalability and elasticity of event-driven for the hot path and the domain isolation of microservices for the broader system
A monolith of any kind is ruled out by the scalability and elasticity requirements. Service-based architecture is eliminated by the real-time event processing needs.
Master Comparison Table: Architecture Styles vs. Key Characteristics
Ratings: ★★★★★ = Excellent, ★★★★☆ = Good, ★★★☆☆ = Moderate, ★★☆☆☆ = Poor, ★☆☆☆☆ = Very Poor
| Architecture Style | Agility | Scalability | Simplicity | Cost | Testability | Deployability | Fault Tolerance | Domain Isolation |
|---|---|---|---|---|---|---|---|---|
| Layered (N-tier) | ★★☆☆☆ | ★★☆☆☆ | ★★★★★ | ★★★★★ | ★★★☆☆ | ★★☆☆☆ | ★★☆☆☆ | ★★☆☆☆ |
| Pipeline | ★★★☆☆ | ★★★☆☆ | ★★★★☆ | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
| Microkernel | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
| Modular Monolith | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★★☆ | ★★★★★ | ★★★☆☆ | ★★★☆☆ | ★★★★☆ |
| Service-Based | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ | ★★★★☆ | ★★★★☆ | ★★★★☆ | ★★★★☆ |
| Event-Driven | ★★★★☆ | ★★★★★ | ★★☆☆☆ | ★★★☆☆ | ★★☆☆☆ | ★★★★☆ | ★★★★★ | ★★★★☆ |
| Space-Based | ★★★★☆ | ★★★★★ | ★☆☆☆☆ | ★☆☆☆☆ | ★★☆☆☆ | ★★★★☆ | ★★★★★ | ★★★☆☆ |
| Microservices | ★★★★★ | ★★★★★ | ★☆☆☆☆ | ★☆☆☆☆ | ★★★★☆ | ★★★★★ | ★★★★★ | ★★★★★ |
| Orchestration-Driven SOA | ★★☆☆☆ | ★★★☆☆ | ★★☆☆☆ | ★★☆☆☆ | ★★☆☆☆ | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
Decision Framework
Use this stepped decision process to narrow down style candidates:
Step 1: How many architecture quanta does the system need?
└─ 1 quantum → Monolithic styles (Layered, Modular Monolith, Microkernel, Pipeline)
└─ Multiple quanta → Distributed styles (Service-Based, EDA, Microservices, Space-Based)
Step 2: What is the primary driver?
├─ Simplicity / Low Cost → Layered or Pipeline
├─ Extensibility / Plugins → Microkernel
├─ Domain isolation, single deploy → Modular Monolith
├─ Domain isolation + independent deploy → Service-Based or Microservices
├─ Real-time event processing / scale → Event-Driven
└─ Extreme elasticity / in-memory speed → Space-Based
Step 3: What are the team constraints?
├─ < 10 people → Avoid distributed systems
├─ 10–50 people → Service-based is the ceiling
└─ 50+ across multiple teams → Microservices viable
Step 4: What is the budget?
├─ Low → Eliminate Microservices and Space-Based
└─ High → All options remain
Step 5: Migration or greenfield?
├─ Greenfield → Choose by requirements
└─ Migration → Modular Monolith as intermediate step
Key Takeaways
- No Universal Best Style: Every architecture style is correct in some context and wrong in others; the architect’s job is matching trade-offs to constraints, not following trends.
- Architectural Fashion Is Dangerous: Each style wave solves real problems — blindly adopting a style without having those problems incurs all costs and gains none of the benefits.
- Quanta Count Drives the Monolith/Distributed Decision: If the system naturally decomposes into one deployable unit, a monolith is structurally appropriate; multiple independently evolving units require distribution.
- Team Size Is a Hard Constraint: Distributed architectures impose operational overhead that small teams cannot sustain; Conway’s Law ensures team structure and system structure converge.
- Microservices Require Microservices Problems: Independent deployability, extreme scalability, and large multi-team organizations are prerequisites — not just aspirations — for microservices to deliver value.
- Silicon Sandwiches → Microkernel or Modular Monolith: Extensibility + simplicity + low cost points to plugin-based or modular single-deployment styles; microservices would be architectural over-engineering.
- Going, Going, Gone → Event-Driven + Microservices: Real-time bidding at internet scale with elastic load requirements eliminates all monolithic styles and points to an event-driven hot path with microservice domain isolation.
- Migrations Should Use Modular Monolith as Intermediate: Decomposing a big ball of mud into a modular monolith is far safer than direct extraction into microservices; services can be carved out later if genuinely needed.
- Budget Is a First-Class Constraint: Cost is a legitimate architectural characteristic; space-based and microservices architectures have infrastructure costs that must be justified by business value.
- The Decision Is Iterative: Initial architecture choices should be made conservatively (simpler style) with explicit migration paths to more complex styles if requirements materialize — evolutionary architecture over big-upfront design.
Related Resources
- ch09-architecture-styles-foundations — Foundational vocabulary: styles vs. patterns, quanta, partitioning types
- ch11-modular-monolith-architecture — Deep dive on modular monolith; when it beats both layered and microservices
- ch13-microkernel-architecture — Deep dive on microkernel/plugin model; fits Silicon Sandwiches scenario
- ch20-architectural-patterns — Patterns that operate within the styles chosen here (CQRS, orchestration, choreography)
Last Updated: 2026-05-29