Business System Design Analysis Method

1. What Is the Requirement?

• Requirement document.
• Prototype.

2. Why Do This Requirement?

• What problem does it solve?
• Can the requirement be avoided?
• Can the requirement be simplified?

3. Requirements Analysis

Understanding a concept should be combined with examples from the system.

3.1. What Is the Existing Flow?

Ask operations or product staff to demonstrate the flow. Read/write flow, B-side/C-side flow.

3.2. What Is the New Flow?

1. What roles exist in the system and what can each role do?
   • Use-Case Diagram
2. What is the flow for each role to perform an action?
   • Flowchart
   • Sequence Diagram

3.3. QPS Estimation

1. Assume DAU is 10 million, each user performs 10 operations, and operations are spread across 24 hours.
2. PV = DAU * 10 = 10 million * 10 = 100 million.
3. Average QPS = PV / 24h = 100 million / (24*60*60) = 1160.
4. Peak QPS = average QPS * 10 = 1160 * 10 = 11600.

3.4. Bandwidth Estimation

Optimization methods: compression and pagination.

4. Solution Design

• Expose API interfaces to clients.
• Internally, combine different data components:
  • Database.
  • Cache.
  • Search engine.
  • Message queue.

4.1. Storage Design

• Choose storage according to functionality, request volume, data volume, stability, scalability, cost, storage model, etc.

• Functionality:

  • Elasticsearch: complex retrieval.
  • MySQL: ACID transactions + persistence.
  • MongoDB: JSON + persistence.
  • Redis: memory.
  • Kafka: peak shaving, asynchronous processing, decoupling.

• Request volume:

  • B-side or C-side.

  Component	Reads per second	Writes per second
  MySQL	10000	5000
  Redis	100000	100000
  Kafka	100000	100000
  MongoDB	20000-50000	10000-25000

• Data volume:

  • Daily data volume = daily request volume * data written per request.
  • How many days to retain.
  • Redis Capacity Estimation
  • How to Estimate Table and Index Space

  Component	Max effective capacity
  MySQL	3TB
  Redis	16GB-128GB
  MongoDB

• Stability:

  • Read/write success rate; refer to service-level-agreement availability.
  • Whether failover is manual or automatic, how long it takes, and its business impact.

• Scalability:

  • Whether rapid scaling is supported and how fast scaling is.

• Data-model design:

  • What entities exist and what relationships exist among them?
  • Data Model
  • ER Diagram

4.2. API Design

1. One API for each operation.
2. Define the API protocol.

4.3. Architecture Design

Consider security, high concurrency, high availability, and maintainability together.

1. Split into microservices.
2. Draw an application architecture diagram.
3. Draw a sequence diagram.

4.4. Code Design

Class Diagram Component Diagram

4.5. Critical Read/Write Paths

5. Effort Estimation

• Estimate 0.5-2 days per API.

6. Development

7. Testing

Functional testing, unit testing, API testing, load testing, etc. Testing

8. Release

1. Service release checklist.
2. Deployment.
   • Deployment Diagram
   • machine count = expected system QPS / QPS per machine. QPS per machine can refer to Load Testing.

9. Operations

2. Organize logs and monitoring for critical paths.
3. Troubleshoot common problems.

10. Optimization

11. Summary

1. Compare solutions.
2. Problems encountered and how they were solved.
3. Design highlights.
   • Why component XXX was introduced.
4. Pain points and improvement measures.
   • How to handle N-times growth in request volume and data volume.
   • Refactoring

12. References

• How to Choose a Data-Storage Architecture?
• Database Selection Guide
• General Approach to Estimating QPS from DAU
• PV, UV, QPS, and Concurrency
• Geek Time