21-Day Study Roadmap for the Shifen Architect Exam: Building the High‑Frequency Scoring Framework

This article presents a 21‑day learning roadmap for the Shifen Architect certification, covering system architecture fundamentals, database and high‑frequency topics, case analysis, and software engineering, with suggested study order, methods, and key concepts for each day.

YiSu Grain
YiSu Grain
YiSu Grain
21-Day Study Roadmap for the Shifen Architect Exam: Building the High‑Frequency Scoring Framework

Overview

The post is a learning map for the first 21 days of the “Shifen Architect” exam preparation, not a complete syllabus. It groups the material into four high‑frequency blocks: core system architecture, database & architecture topics, case analysis, and software engineering.

Learning Approach

The author emphasizes a practical method: avoid reading books cover‑to‑cover, skip highlighting, focus on high‑frequency scoring points, use doodles for recall, self‑test to confirm understanding, and finally store the knowledge on a mental “shelf”. The goal is to gain a few points each day rather than cramming many.

Week 1 – Core System Architecture

Days 01‑07 introduce the fundamentals of distributed systems:

Day 01 – CAP and BASE, explaining consistency vs. availability trade‑offs and why Zookeeper is CP while Eureka is AP.

Day 02 – Distributed transactions, covering 2PC, TCC, and Saga, and why cross‑service transactions are more complex than single‑database ones.

Day 03 – Microservice decomposition by business capability, its benefits (independent development, deployment, scaling) and drawbacks (communication, transaction, operations, monitoring).

Day 04 – Service governance, including service registration/discovery, API gateway, load balancing, rate limiting, circuit breaking, and degradation.

Day 05 – Cache architecture, discussing Redis cache purpose, cache avalanche, cache penetration, cache breakdown, Bloom filter, distributed lock, and logical vs. physical expiration.

Day 06 – Kafka and message queues, describing asynchronous decoupling, peak‑shaving, and the roles of Topic, Partition, Replica, Offset, and Consumer Group.

Day 07 – System‑architecture overview, showing how user requests flow through gateway, load balancer, order service, and interact with Redis, database, and Kafka, emphasizing diagramming over memorizing terms.

Week 2 – Database & Architecture High‑Frequency

Days 08‑14 focus on database internals and reliability:

Day 08 – MySQL indexes and B+Tree, explaining why B+Tree suits indexes, clustered vs. non‑clustered indexes, back‑table lookup, covering indexes, and leaf‑node linked lists for range queries.

Day 09 – ACID and isolation levels, defining transactions, the four ACID properties, dirty read, non‑repeatable read, phantom read, and MySQL InnoDB’s default repeatable‑read.

Day 10 – MVCC and locking, introducing MVCC, undo log, version chain, read view, snapshot vs. current reads, and various lock types (optimistic, pessimistic, row, table, gap, next‑key).

Day 11 – High‑availability architecture, stating that HA means surviving failures, covering redundancy, fault detection, failover, degradation, and deployment patterns (master‑slave, active‑active, multi‑active) plus RTO/RPO.

Day 12 – Performance‑optimization tactics, stressing bottleneck identification, metrics (response time, throughput, concurrency, resource utilization), and techniques such as caching, async processing, DB tuning, horizontal scaling, rate limiting, and degradation.

Day 13 – Case‑analysis template, teaching how to read questions, identify problems, select templates, map technical points to business scenarios, and use the standard sentence pattern “For xxx problem, adopt xxx solution, used for xxx, thus xxx.”

Day 14 – Week‑2 recap, linking Days 08‑13 into a single e‑commerce high‑concurrency diagram and showing how to answer comprehensive case questions, highlighting the key sentence “Display inventory can be stale, but commit inventory must be fresh.”

Week 3 – Software Engineering High‑Frequency

Days 15‑21 cover software‑engineering fundamentals and exam‑friendly topics:

Day 15 – Software development models, listing Waterfall, V‑model, Prototyping, Spiral, Incremental, Iterative, Agile, Scrum, and providing selection rules based on requirement stability, testing needs, risk, delivery cadence, and change speed.

Day 16‑21 (planned) – Requirements engineering & UML overview, UML diagram specialties, design principles & patterns (SOLID, Singleton, Factory, Adapter, Decorator, Proxy, Observer, Strategy), software testing types, CMMI levels, and a final software‑engineering week recap with a “from requirement to test” flowchart and practice questions.

Future Updates

The author plans to add weeks on networking, operating systems, security, reliability, project management, thesis & case‑question practice, and real‑exam review.

How to Start

If you are a beginner, begin with Day 00. To focus on architecture, study Days 01‑07; for database and high‑concurrency, study Days 08‑14; for software‑engineering multiple‑choice points, start at Day 15; and for case‑question preparation, prioritize Days 12‑14.

Final Advice

The series promotes learning a small chunk each day, understanding, visualizing, teaching, self‑testing, and gradually building a personal knowledge “shelf” to accumulate points steadily.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

distributed systemssystem architecturedatabaseSoftware Engineeringexam preparation
YiSu Grain
Written by

YiSu Grain

A fleeting mayfly in the world, a single grain in the boundless sea.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.