Key Takeaways from “System Architecture Design”: A Structured Overview

1. Book Overview

Title: System Architecture Design: Methods for Building Complex Systems

Positioning: Systematic textbook on architecture design

Core Content: Complete guidance from methodology to practice

2. Essence of Architecture

2.1 What is Architecture

Definition: Architecture is the fundamental structure of a system together with the principles and guidelines for creating that structure.

Architecture = Structure + Principles + Decisions

2.2 Core Questions

What components make up the system? → Component decomposition

How do components relate? → Dependency relationships

What is the basis for decisions? → Quality attributes

2.3 Design Goals

┌─────────────────────────────────────┐
│           Architecture Goals       │
├─────────────────────────────────────┤
│  ✓ Meet functional requirements    │
│  ✓ Meet quality requirements (performance, availability, etc.) │
│  ✓ Be realizable, deployable, maintainable │
│  ✓ Balance stakeholder interests   │
└─────────────────────────────────────┘

3. Quality Attributes

3.1 Classification

Quality Attributes
├── Runtime Quality
│   ├── Performance
│   ├── Availability
│   ├── Security
│   └── Reliability
└── Development-time Quality
    ├── Maintainability
    ├── Scalability
    ├── Testability
    └── Deployability

3.2 Key Attributes

Performance: System response speed; measured by response time, throughput.

Availability: System uptime ratio; e.g., 99.9%, 99.99%.

Scalability: Ability to handle growth; horizontal or vertical scaling.

Security: Data protection; authentication, authorization, encryption.

Maintainability: Ease of modification; change cost, code complexity.

3.3 Example Scenario (Performance)

Quality Attribute Scenario: Performance
Stimulus Source: User request
Stimulus: 10,000 QPS concurrent requests
System Under Test: Order service
Environment: Normal operation
Response: Process request
Response Metric: P99 latency < 500 ms

4. Architectural Styles

4.1 Style Catalog

Layered architecture

Client‑server

MVC

Microservices

Event‑driven

Pipe‑filter

Space‑based

4.2 Layered Architecture

┌─────────────────────┐
│      Presentation   │
├─────────────────────┤
│        Business     │
├─────────────────────┤
│   Data Access Layer │
├─────────────────────┤
│   Infrastructure    │
└─────────────────────┘

Characteristics: clear layer boundaries, each layer depends only on the one below, easy to understand and maintain.

Applicable scenarios: enterprise applications, traditional web apps, complex but stable business logic.

4.3 Microservices

┌────────┐  ┌────────┐  ┌────────┐
│ Service A │ │ Service B │ │ Service C │
└───┬───────┘  └───┬───────┘  └───┬───────┘
    │            │            │
    └───────┬───────┘
            │
        ┌──────▼──────┐
        │ Service Registry │
        │      Center      │
        └──────────────────┘

Characteristics: independent deployment, technology diversity, independent scaling.

Applicable scenarios: large‑scale internet apps, fast‑iteration business, multi‑team collaboration.

4.4 Event‑Driven Architecture

┌────────┐    ┌────────┐    ┌────────┐
│ Event  │ → │ Message │ → │ Event   │
│ Publish│    │ Queue   │    │ Consume │
│ Service│    │         │    │ Service │
└────────┘    └────────┘    └────────┘

Characteristics: loose coupling, asynchronous processing, strong scalability.

Applicable scenarios: real‑time data processing, log collection/analysis, asynchronous task handling.

5. Architecture Design Methodology

5.1 Design Process

┌──────────┐
│ Requirement Analysis │ ← Understand what the system must do
└────┬─────┘
     ↓
┌────▼─────┐
│ Determine Architecture │ ← Choose driving factors and style
└────┬─────┘
     ↓
┌────▼─────┐
│ Conceptual Architecture │ ← High‑level design
└────┬─────┘
     ↓
┌────▼─────┐
│ Detailed Architecture │ ← Refine design
└────┬─────┘
     ↓
┌────▼─────┐
│ Architecture Validation │ ← Review and verify
└──────────┘

5.2 Conceptual Design Deliverables

System module decomposition

Module responsibilities

Module relationship description

Key technology decisions

Architecture views

5.3 Detailed Design Deliverables

Interface definitions

Data models

Deployment scheme

Technology selection

Detailed design documentation

6. Architecture Decisions

6.1 Decision Types

Structural decisions – how the system is organized (e.g., microservice decomposition)

Interface decisions – how components interact (e.g., REST API)

Technology decisions – which technology to use (e.g., MySQL vs MongoDB)

Deployment decisions – where to run (e.g., cloud vs on‑premise)

6.2 Decision Process

1. Identify the problem
   - What needs to be solved?
2. Gather information
   - What options exist?
   - What are their pros and cons?
3. Analyze trade‑offs
   - Evaluate each option
   - Weigh benefits against drawbacks
4. Make a decision
   - Choose the best option
   - Record the rationale
5. Communicate the decision
   - Explain to stakeholders
   - Obtain approval

6.3 Architecture Decision Record (ADR) Example

# ADR-XXX: Messaging Queue Selection
## Status
Approved
## Background
System needs a message queue.
## Candidates
1. Kafka – high performance, big‑data friendly
2. RabbitMQ – feature‑rich, easy to use
3. RocketMQ – Alibaba open‑source, Chinese‑friendly
## Evaluation Criteria
- Performance
- Reliability
- Usability
- Operational cost
## Decision
Select: Kafka
## Rationale
1. High throughput requirement
2. Team has Kafka experience
3. Active community and good documentation
## Risks
- Learning curve
- Operational complexity

7. Architecture Validation

7.1 Validation Methods

Architecture review – expert assessment of the design

Prototype verification – build a prototype to test feasibility

Performance testing – validate performance targets

Scenario analysis – verify key usage scenarios

7.2 Review Checklist (excerpt)

Functional completeness – all functional requirements covered, edge cases considered

Quality attributes – performance goals achievable, availability ensured, security addressed

Feasibility – technical solution viable, resources sufficient

Maintainability – reasonable module division, clear interface definitions

8. Documentation

8.1 Document Types and Audiences

Architecture overview – for all stakeholders, overall design

Detailed design – for developers, technical details

Interface documentation – for integrators, API definitions

Deployment guide – for operations, deployment and ops procedures

8.2 Documentation Template (outline)

# System Architecture Design Document
## 1. Overview
## 2. Requirement Analysis
## 3. Architecture Design
## 4. Detailed Design
## 5. Interface Definition
## 6. Data Model
## 7. Deployment Plan
## 8. Monitoring & Operations

9. Summary of Key Points

Drive design with quality attributes.

Select an appropriate architectural style.

Make decisions explicit and recorded.

Continuously validate the architecture.

Document the design throughout the lifecycle.

Architecture design is not a one‑off activity; it is a continuous effort throughout the software lifecycle.