Five Critical Questions to Test Your System Design’s Reasonableness

When judging whether a technical design is reasonable, we must first define the evaluation dimensions; without a shared standard, projects become as hard to implement as solving a four‑dimensional paradox.

1. Data Consistency

The CAP theorem states that consistency, availability, and partition tolerance cannot be achieved simultaneously. The article visualizes this with an "impossible triangle" and draws a parallel to the investment triangle (liquidity, return, risk). In practice, developers focus on consistency because inaccurate data directly impacts business logic.

2. Isolation and Clear Boundaries

Memory and disk are separated to serve different needs: fast access versus durable storage. From a single‑responsibility perspective, each handles its own domain without interference. Real‑world isolation techniques include redundant tables/fields, bounded‑context domain models, microservice boundaries, and anti‑corruption layers, promoting high cohesion internally and low coupling externally.

3. Extensibility for Business Change

Extensibility hinges on abstraction. During PRD analysis, identify which data models, tables, or fields may need future expansion. For example, a single table storing both sales and after‑sale orders would require additional columns for new order types; instead, abstract to a generic "document type" plus a business identifier.

4. Correct Business Sequencing

Accurate sequencing prevents logical errors, such as creating a payment record asynchronously and then synchronously operating on it before the async task finishes. Managing the lifecycle of data—when it is created, operated on, archived, or destroyed—ensures logical consistency.

5. High‑Concurrency Resilience

High concurrency tests a system’s read/write throughput. Identify whether the workload is read‑heavy or write‑heavy and apply appropriate tactics: cache preloading for reads, enforce write ordering or batch writes for writes. After understanding resource bottlenecks (CPU, IO, memory), calculate peak resource limits as "peak = average × peak count". If a single node saturates, scale out or introduce middleware for throttling, circuit‑breaking, and load‑shedding, achieving the "three‑high" goal of high concurrency, performance, and scalability.

Overall, architecture is a form of resource management—organizing CPU, memory, disk, and network to meet design goals. By mapping new thinking methods to concrete problems (e.g., via mind maps) and building meta‑capabilities, engineers can turn abstract principles into repeatable processes that reduce cost and increase efficiency.