architecture-design

Intelligent Technology Architecture Solution Generator

Task Objectives

This Skill is used to help users start from vague requirements and gradually build an implementable, clearly structured, and evolvable technology architecture solution.

• Capabilities include: requirements analysis, technology selection evaluation, architecture design, alternative solution recommendations, solution output
• Trigger conditions: the user raises needs such as "design architecture", "technology selection", "system design", or needs to evaluate a technical solution

Operation Steps

Step 1: Collect Information

Ask the user for the following key information. If the information is insufficient, proactively ask questions; do not assume:

Required information:

1. Core business objectives or functions to be implemented (for example: "build a live quiz system that supports 10,000 concurrent users")
2. Technology stack already considered or preferred (frontend/backend/database/middleware, etc.; leave blank if none)

Important supplementary information: 3. Non-functional requirements:

• Expected concurrency (such as 1000 QPS, 100,000 DAU)
• Response time requirements (such as < 100ms, < 1s)
• Data security requirements (such as data encryption, access control)
• Availability requirements (such as 99.9%, 99.99%)

1. Deployment environment constraints (such as must use a certain cloud vendor, need to build an on-premises data center, budget constraints, etc.)
2. Team technology stack preferences (such as the team is familiar with Java/Go/Python)

Step 2: Clarify Requirements & Supplement Technology

Requirements analysis:

• Identify core modules (user management, business logic, data storage, messaging, monitoring and logging, etc.)
• Analyze key interaction flows (the complete链路 from user request → processing → response)
• Identify performance bottleneck points (hot data, high-frequency queries, long transactions, etc.)

Technology stack evaluation:

• Against the technology stack provided by the user, evaluate its applicability:
  • Whether it meets performance requirements (such as whether SQLite can support high concurrency)
  • Whether it suits the business scenario (such as whether MongoDB is appropriate for relational data)
  • Whether there are technical risks (such as an immature ecosystem for a new framework)
• If the technology stack is insufficient or inappropriate, proactively propose alternatives and explain the reasons

Common problem identification:

• Missing necessary components (no cache, no message queue, no monitoring system)
• Architecture design flaws (single point of failure, no disaster recovery, data consistency not considered)
• Technology selection mismatch (such as using a relational database to handle document-oriented data)

Step 3: Iterate and Refine

Present the preliminary architecture: Present the architecture in a modular way, including:

• Frontend layer (Web, mobile, mini programs, etc.)
• API gateway layer
• Service layer (core business services)
• Data layer (database, cache, file storage)
• Infrastructure layer (deployment, monitoring, logging, security)

Technology selection solution: For each module, provide:

• Recommended technology (primary option)
• Alternative options (substitute solutions)
• Selection criteria (performance, ecosystem, learning cost, maintenance cost)

Proactive guidance:

• Ask the user whether they have preferences or constraints regarding certain technologies (e.g., "Must a cloud provider be used? Is Serverless acceptable?")
• Confirm whether key non-functional requirements have been met
• Determine whether the team's technical capabilities match the recommended solution

Iterative optimization: Adjust the solution based on user feedback, focusing on:

• Whether the cost is acceptable
• Whether the team can handle it
• Whether the risks are controllable
• Whether it has the ability to evolve

Step 4: Output the final solution

Output the complete architecture recommendation in a clear structure, including the following content:

1. Overall architecture diagram Use Mermaid syntax or a layered description, for example:

前端层
  ├─ Web 应用 (React/Vue)
  ├─ 移动应用 (Flutter/React Native)
  └─ 小程序

API 网关层
  ├─ 路由分发
  ├─ 鉴权认证
  └─ 限流熔断

服务层
  ├─ 用户服务
  ├─ 订单服务
  ├─ 支付服务
  └─ 通知服务

数据层
  ├─ 关系数据库 (MySQL/PostgreSQL)
  ├─ 缓存 (Redis)
  ├─ 搜索引擎
  └─ 消息队列 (Kafka/RabbitMQ)

基础设施层
  ├─ 容器编排
  ├─ 监控告警 (Prometheus + Grafana)
  ├─ 日志收集 (ELK)
  └─ CI/CD 流水线

2. Technology selection and rationale for each module Explain in table or list form:

• Module name
• Recommended technology
• Selection rationale (performance, reliability, ecosystem, cost, team skills)
• Alternative options and switching scenarios

3. Key data flows or interaction processes Describe the data flow paths of the core business, for example:

用户请求 → API 网关 → 鉴权服务 → 业务服务 → 数据库 → 响应返回

4. Key points of scalability and disaster recovery design

• Horizontal scaling strategy (stateless design, sharding, read/write separation)
• High availability design (multi-availability-zone deployment, failover)
• Data consistency solutions (transactions, eventual consistency, compensation mechanisms)
• Disaster recovery and backup strategy (regular backups, multi-site active-active)

5. Recommendations for subsequent evolution

• V1 phase (MVP): Rapidly validate the business, monolithic architecture, focus on core functionality
• V2 phase (growth stage): Split core services, introduce caching, optimize performance
• V3 phase (maturity stage): Microservices, containerization, automated operations
• Evolution milestones and technical debt management

Resource index

• Domain reference: see references/tech-selection-guide.md(technology selection reference manual, including recommended solutions and technology comparisons for common scenarios)

Notes

• Avoid over-engineering: prioritize mature technologies with active communities that are easy for the team to adopt
• Pragmatism: solutions must be implementable; do not consider fancy technologies with no practical value
• Cost awareness: balance performance, reliability, and cost, and avoid resource waste
• Evolution capability: the design must be scalable and support future business growth
• Team fit: technology selection must take into account the team's capabilities and learning cost
• Risk control: identify potential risks and provide response plans

Usage examples

Example 1: E-commerce system architecture design

• Function description: Design a technical architecture for a medium-sized e-commerce platform
• Requirement information: 100,000 DAU, support flash sale events, requires high availability
• Execution method: The agent leads the four-step process and looks up technology selection recommendations for e-commerce scenarios in references/tech-selection-guide.md
• Key output: Layered architecture diagram, technology selection table, flash sale scenario design plan, evolution roadmap

Example 2: SaaS platform technology selection

• Function description: Evaluate technical solutions for a multi-tenant SaaS platform
• Requirement Information: Needs to support multi-tenant isolation, high data security requirements, limited budget
• Execution Method: The agent analyzes multi-tenant scenario requirements and compares database solutions (independent database vs shared database)
• Key Outputs: Comparison of multi-tenant isolation solutions, database selection recommendations, cost estimates, risk alerts