From Tech Terms to Real Architecture Design: Day22‑Day42 Learning Roadmap

Stage Overview

Having built a high‑frequency scoring foundation in Days 01‑21, the next phase moves from merely recognizing technologies to actually designing system architectures.

Core of Architecture Design

This stage asks not only "what is this technology?" but also:

Who are the system stakeholders?

Where do architecture requirements originate?

How to describe an architecture?

How to balance conflicts among performance, availability, and security?

Why choose a particular architectural style?

How to evaluate an architecture solution?

How do different industry systems prioritize architectural concerns?

Learning Rules

Each "Day" represents a learning session, not a calendar date. Complete one Day per session; missed days are not made up, and two Days are never done simultaneously.

Do not chase the calendar; advance the count of learning sessions.

From Day 22 to Day 84 there are 63 learning sessions. Maintaining 4‑5 sessions per week ensures the plan stays on track while leaving a small buffer.

Three‑Pass Learning Method

First Pass: Identify Knowledge and Build Shelves (Day01‑Day56)

Goal: Recognize the knowledge area of each exam question, state basic concepts, applicable scenarios, and main distinctions.

Sketch recall

3‑minute explanation

10 self‑test questions

Day 22‑Day 42 still belongs to the first pass, focusing on solidifying the core architecture shelves.

Second Pass: Apply Knowledge in Cases and Papers (Day57‑Day70)

Goal: Move beyond definitions to propose architecture solutions for business problems.

Case‑based point answers

Architecture proposals

Paper outlines

Complete papers

Third Pass: Real‑Exam Error Correction and Timed Output (Day71‑Day84)

Goal: Stabilize scoring by reducing concept confusion, missed cases, and time overruns.

Mock exams

Error attribution

Timed case studies

Timed papers

Overall Learning Plan Position

The full roadmap is:

Day01‑Day21: Build high‑frequency scoring skeleton

Day22‑Day42: Core architecture design and specialty architectures

Day43‑Day56: Comprehensive peripheral knowledge and material gap checking

Day57‑Day63: Second‑pass case analysis

Day64‑Day70: Second‑pass papers

Day71‑Day84: Real‑exam sprint

We are now in the second part:

Day22‑Day42: Core Architecture Design and Specialty Architectures

This stage spans 21 learning days, organized into three weekly units of 7 Days each, requiring 4‑5 sessions per week (approximately 4‑5 calendar weeks).

Learning Objectives for the Second Stage

After completing Day22‑Day42, learners should acquire four capabilities:

1. Understand What Architecture Questions Ask

Architecture lifecycle

Architecture views

Quality attributes

Architecture styles

Design methods

Evaluation techniques

Specific specialty architectures

2. Derive Architecture Solutions from Business Problems

Examples of business prompts and the corresponding architectural concerns:

System cannot be down for long → Availability

Peak traffic spikes → Performance & elasticity

Independent team development → Modularity & service boundaries

Real‑time data processing → Stream processing architecture

Sensitive operations need audit → Security & audit mechanisms

3. Explain the Rationale Behind Choices

Answers must go beyond stating components (e.g., "use cache, load balancer, message queue"). They must explain why each is chosen, what problem it solves, and what trade‑offs it introduces.

For hot‑data access causing DB pressure, introduce Redis cache to store frequent data in memory, reducing DB hits, shortening response time, and increasing throughput; also address cache consistency, penetration, breakdown, and avalanche issues.

4. Produce an Architecture Knowledge Map

Architecture requirements → Quality attributes → Architecture views → Architecture styles → Architecture decisions → Architecture evaluation → Architecture evolution

This map becomes the entry point for later cases and papers.

Second‑Stage Daily Curriculum

Week 4: Architecture Design & Quality Attributes

Day22: System architect responsibilities & architecture lifecycle – stakeholders, requirements, design, documentation, implementation, evaluation, evolution

Day23: Architecture views & description – viewpoints, 4+1 view model (logical, process, development, physical, scenario)

Day24: Quality‑attribute scenarios – source, stimulus, environment, artifact, response, response metric

Day25: Classic software architecture styles – data flow, call‑return, independent component, virtual machine, data center

Day26: Architecture design methods – requirement‑driven, quality‑attribute‑driven, ABSD, decisions & constraints

Day27: Architecture evaluation – SAAM, ATAM, scenarios, sensitivity points, trade‑offs, risk points, non‑risk points

Day28: Core architecture weekly review – select style based on business quality attributes and solve a case

Week 5: Information Systems & Modern Architecture

Day29: Information system architecture – business, data, application, technology layers; enterprise architecture basics

Day30: Layered architecture – presentation, business, data access, data layers; MVC; PetShop example

Day31: Cloud‑native architecture – service‑orientation, elasticity, observability, resilience, automation, zero‑trust, continuous evolution

Day32: SOA architecture – services, contracts, loose coupling, ESB, Web Service, orchestration

Day33: Microservices (second pass) – DDD boundaries, data autonomy, service mesh, observability, distributed governance

Day34: Architecture evolution & maintenance – reasons for evolution, maintenance types, refactoring, migration, legacy handling

Day35: Modern architecture weekly review – compare layered, SOA, microservices, cloud‑native; draw evolution roadmap

Week 6: Specialty Architectures

Day36: Embedded system architecture – real‑time, HW/SW co‑design, reliability, embedded OS

Day37: Communication system architecture – network protocols, layering, QoS, reliable transmission

Day38: Security architecture – security domains, authentication, authorization, audit, zero‑trust, defense‑in‑depth

Day39: Big‑data architecture – distributed storage, batch processing, stream processing, compute‑storage separation

Day40: Data warehouse & data lake – ETL, OLAP, dimensional modeling, Lambda/Kappa, lake‑warehouse integration

Day41: Future information technologies – IoT, edge computing, AI, blockchain and their architectural impact

Day42: Specialty architecture weekly review – identify eight categories of architecture questions and produce a comprehensive specialty‑architecture map

Mindset Shift in This Stage

In the first stage we asked "What is Redis? What is a message queue? What is microservices?" The second stage asks deeper questions such as:

Why does the system need caching? Why is asynchronous processing suitable here? Why split into microservices? What is sacrificed by the split? How to trade off performance, availability, and consistency? How to justify the architecture solution?

Architecture design is not a stack of technical terms; it is about making reasoned, explainable choices among business goals, quality attributes, technical constraints, and costs.

Starting Day 22, the goal is to transform the mental "architecture shelves" into a usable knowledge store that can be located and invoked when needed.