2026 System Architecture Designer Exam: Case Analysis Questions & Reference Answers
This article presents five case analysis questions from the May 2026 System Architecture Designer exam, covering time-series databases, MQTT QoS levels, concurrency control strategies, knowledge graph construction, and pipe-filter architecture for intrusion detection, with detailed reference answers for each scenario.
Note: This content is compiled from community recollections; question order and some details may differ from the actual exam. Answers are personal reference solutions for study purposes only; refer to official releases for authoritative information.
Question 1: Smart Elderly Care Home System
Sub-question 2: Time-Series Data and Time-Series Database
Question: Explain what time-series data is and why a time-series database is suitable for the edge gateway layer in this system (within 300 words).
Reference Answer:
Time-series data is a sequence of data points recorded in chronological order with timestamps, reflecting the trend of a metric over time. In this system, sensor-collected data such as temperature, humidity, electrical load, and device status all belong to time-series data.
Reasons for using a time-series database at the edge gateway layer:
1. High write performance , suitable for continuous writes of high-frequency sensor data.
2. High data compression ratio , saving limited storage space on edge gateways.
3. Support for time-window queries and aggregation analysis , enabling quick identification of environmental anomalies.
4. Support for data sampling and expired data cleanup , reducing data maintenance costs.
5. Time-series data is predominantly append-only writes , matching the storage and query characteristics of time-series databases.
Sub-question 3: MQTT Quality of Service Levels
Question: Analyze the appropriate MQTT QoS level for different critical business scenarios and explain why some businesses require QoS 2.
(1) QoS Levels per Business Scenario:
Environmental sensing (temperature, humidity, light, air quality periodic reporting) → QoS 0
Water/electricity metering (ordinary meter data reporting) → QoS 1
Fall confirmation alarm (fall event reporting, rescue triggering) → QoS 2
One-click help (emergency help button messages) → QoS 2
Robot normal status (battery, location, online status) → QoS 1
Robot emergency linkage (emergency handling after fall/help) → QoS 2
(2) Why Critical Businesses Use QoS 2:
Fall alarms, one-click help, and robot emergency linkage are critical businesses affecting elderly life safety. They must avoid message loss and duplicate delivery as much as possible. MQTT QoS 2 achieves exactly-once delivery at the protocol receiver through a four-step handshake, reducing the impact of duplicate messages, and is suitable for scenarios with high message delivery semantic requirements.
Note: QoS 2 does not guarantee absolute no-loss or no-duplicate execution across the entire business flow; the application layer still needs timeout handling, state verification, and idempotency mechanisms.
Question 2: Adaptive Learning and Intelligent Tutoring System
Sub-question 2: Cold Start Problem
(1) Solving User Cold Start:
1. Leverage registration information: Collect subject preferences, learning goals, and existing knowledge base to build an initial user profile.
2. Adopt general recommendation strategies: Initially recommend popular learning resources, basic courses, or expert-annotated learning paths.
3. Conduct initial capability assessment: Estimate the student's initial knowledge level through simple questionnaires and knowledge point tests.
4. Utilize contextual information: Combine current learning task and other context to assist recommendations.
5. Continuously collect feedback: Dynamically adjust recommendation results based on student clicks, answers, and completion.
(2) Other Two Types of Cold Start:
Item cold start: New courses, new exercises lack user interaction data, making accurate recommendation difficult.
System cold start: When a new platform launches, there is insufficient user historical behavior and item rating data to build an effective recommendation model.
Sub-question 3: Knowledge Graph Sparsity
(1) Three Key Steps to Build a Knowledge Graph:
1. Knowledge Extraction: Extract knowledge entities, entity relationships, and relevant attributes from textbooks, exercises, and learning records.
2. Knowledge Fusion: Align entities from different sources, handle duplication, conflicts, and inconsistencies.
3. Knowledge Processing and Storage: Represent, associate, store, and validate knowledge quality, and perform relationship reasoning as needed.
(2) Causes of Sparsity from Path Reasoning and Mastery Estimation Perspectives:
1. Path Reasoning Perspective: Sparse prerequisite dependencies between basic knowledge points lead to a lack of complete reasoning paths between mastered knowledge points and target exercises, making it difficult for the system to generate progressive learning paths and prone to recommending high-difficulty questions lacking prerequisite support.
2. Mastery Estimation Perspective: Insufficient associations between knowledge points prevent the system from fully utilizing related knowledge point answer records to correct mastery estimates, potentially misjudging the actual level of students with weak foundations, thereby affecting exercise recommendation effectiveness.
Question 3: E-commerce Flash Sale System
Sub-question 1: Pessimistic Lock Classification and Differences
Question: List at least two categories of pessimistic locks and analyze their differences.
Reference Answer:
Common pessimistic locks include shared locks and exclusive locks.
1. Shared Lock (Read Lock): Multiple transactions can hold a shared lock on the same data simultaneously, allowing reads but restricting conflicting write operations.
2. Exclusive Lock (Write Lock): Typically only one transaction can hold an exclusive lock on the same data; other transactions cannot acquire conflicting locks, ensuring write operation exclusivity.
Shared locks suit read scenarios needing to prevent concurrent modifications; exclusive locks suit scenarios requiring exclusive data modification. Specific lock compatibility rules depend on the DBMS implementation.
Sub-question 2: Optimistic Lock Implementation and Pros/Cons
Optimistic Lock Implementation Approaches:
1. Application Level: Add a version field to the data table. Retrieve the current version when reading data; update with a version condition. If affected rows = 0, data has changed; retry or abort.
2. DBMS Management Level: Use database-supported concurrency control mechanisms to detect transaction write conflicts. On conflict, the database rejects commit or rolls back the transaction; specifics depend on isolation level and concurrency control mechanism.
Pros and Cons of Pessimistic vs Optimistic Locks:
Pessimistic Lock: Pros: Directly controls concurrent access, suitable for high-contention scenarios. Cons: Lock contention may cause blocking, deadlocks, and concurrency performance degradation.
Optimistic Lock: Pros: Reduces lock waiting, suitable for low-conflict-probability scenarios. Cons: Conflicts require retries; in high-concurrency write scenarios, may generate large retry overhead.
Sub-question 3: High-Concurrency Optimization Strategies with Redis
Strategy 1: Redis Atomic Operations for Inventory Control. Preload inventory into Redis; use Lua scripts to atomically check and deduct inventory, avoiding concurrent competition. On successful deduction, asynchronously update the database via message queue with failure compensation mechanisms.
Strategy 2: Use WATCH for Optimistic Concurrency Control. Monitor relevant keys with WATCH; during MULTI/EXEC transaction execution, detect concurrent modifications. If watched keys change, EXEC may fail; application layer can retry based on situation. Control retry counts under high concurrency to avoid extra pressure.
Strategy 3: Adopt Distributed Locks. Use Redis SET NX EX mechanisms for resource mutex. Set unique identifier and expiry when acquiring lock; verify identifier when releasing to avoid deleting another client's lock. For critical businesses like inventory, consider lock renewal, failure recovery, and business idempotency.
Strategy 4: Cache Hotspot Data. Place product details, activity configurations, and other hotspot data in Redis to reduce database access pressure, combined with mutex locks, logical expiration, etc., to mitigate cache penetration issues.
Question 4: Intelligent Security AIoT System
Sub-question 1: Four-Layer Architecture Main Functions
1. Perception Layer: Collects raw data such as video, environment, and identity recognition; typical devices include cameras, smart access control, and various sensors.
2. Edge Layer: Performs data preprocessing, real-time analysis, and local response near the data source, reducing communication latency and supporting offline autonomy under certain conditions.
3. AI Decision Layer: Responsible for multi-source data fusion, intelligent analysis, event judgment, model training, and model update management.
4. Application Layer: Provides user-facing functions such as alarm push, contingency plan execution, mobile apps, and third-party system integration.
Sub-question 3: Five Drawbacks of the Four-Layer Architecture
1. Limited Edge Device Computing Power: Hardware constraints may prevent complex models from running efficiently on edge devices.
2. Difficult Model Synchronization: Improper model updates and version management can lead to inconsistent model versions across devices.
3. Increased Security Risks: Distributed edge nodes may be subject to physical attacks, malicious tampering, or network attacks.
4. High Operational Complexity: Heterogeneous devices and multi-layer components increase deployment, upgrade, monitoring, and troubleshooting difficulty.
5. Data Privacy Risks: Collection, storage, and transmission of sensitive data like video and facial recognition require strict access control, encryption, and audit mechanisms.
Question 5: Real-time Network Intrusion Detection System
System requirements include role-based access, 1-second query response under normal load, unique alarm event IDs starting with letters, immediate rejection and audit logging of unauthorized access within 1 second, 2-second analysis and alarm generation, 5-second failover to standby node, horizontal scaling support within 2 person-days, 5-second hot backup recovery after crash, and configuration changes for security policy updates within 4 person-days.
Sub-question 1: Quality Attribute Requirement Identification
Mapping of Quality Attributes to Requirements:
Availability: Requirements (f) and (h)
Performance: Requirements (b) and (e)
Modifiability: Requirements (g) and (i)
Security: Requirements (d) and (j)
Quality Attribute Scenario for Requirement (d):
Stimulus Source: Unauthorized user.
Stimulus: Attempt to access system backend or modify detection rules.
Environment: During normal system operation.
Artifact: System backend management functions and detection rule configuration modules.
Response: System rejects the illegal request and logs the privilege escalation to the security audit log.
Response Measure: Time from initiating illegal request to completing rejection and logging ≤ 1 second.
Sub-question 2: Architectural Style Selection and Component Design
(1) Suitable Architectural Style: The system is better suited to the Pipe-Filter architectural style .
Reasons:
1. Meets real-time streaming processing needs: Continuous network traffic arrival; pipe-filter organizes collection, preprocessing, feature extraction, intrusion detection, and alarm handling into a continuous data processing pipeline.
2. Reduces module coupling: Each processing step can be independently designed, developed, and maintained, facilitating adjustment of detection algorithms or addition of new processing steps.
3. Facilitates scaling: Processing nodes can be scaled according to load, improving system throughput.
4. Batch processing style is unsuitable: Batch processing typically collects a batch of data before unified processing, unable to meet continuous traffic analysis and real-time alarm requirements.
(2) Required Components: Based on pipe-filter architecture, the following components can be designed:
1. Traffic Collection Filter
2. Data Preprocessing Filter
3. Feature Extraction Filter
4. Intrusion Detection Filter
5. Alarm Generation Filter
6. Alarm Output Filter
7. Pipe Component connecting filters and transmitting processed data
Additionally, supporting components for user role management, security audit, configuration management, node monitoring, and failover are needed per system requirements.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Code of Duty
"Code of Duty" — Every line of code has its own mission. We avoid shortcuts and quick fixes, focusing on authentic coding reflections and the joys and challenges of technical growth. The journey of learning matters more than any destination. Join us as we humbly forge ahead in the world of code.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
