How to Turn Thinking Frameworks into Powerful Architecture Strategies

Thinking and Practice Frameworks

The OGSM model (Objective‑Goal‑Strategy‑Measurement) provides a repeatable way to turn vague business intent into concrete, measurable engineering actions.

Objective : Clarify the high‑level purpose (e.g., improve user latency).

Goal : Decompose the objective into quantifiable sub‑goals such as specific KPI/OKR values (e.g., reduce 95th‑percentile response time to 200 ms).

Strategy : Choose concrete tactics—code‑coverage targets, pair programming, automated tests, caching, etc.

Measurement : Define metrics and monitoring that can verify each goal.

Iterate : Use the measured data to adjust goals and tactics in short cycles.

Internet Iteration Thinking

Rapid feedback loops and continuous improvement are modeled by the Product‑Lifecycle (PLC) curve, which describes stages from market entry to retirement. The iterative mindset encourages releasing minimal viable functionality, collecting real‑world data, and evolving the system incrementally.

5W1H Analysis Method

Applying the six‑question framework (What, Why, Where, When, Who, How) to a technology choice yields a systematic decision record. The following Redis example illustrates the approach:

What : In‑memory key‑value store supporting string, list, set, hash, sorted‑set.

Why : Need a distributed cache that exceeds local‑process memory limits.

Where : Deploy between gateway and DAO layers to offload database reads.

When : Triggered by QPS or latency thresholds that indicate database bottlenecks.

Who : Architects and backend engineers responsible for performance.

How : Consult the official Redis API documentation and sample code.

Applying Models to Architecture Design

Adopt a goal‑driven action framework to define clear architectural objectives.

Assess the current state using standard criteria (availability, performance, scalability).

Iterate in small, measurable steps; prioritize targets that deliver the highest impact.

Recognize that best practices evolve; treat them as hypotheses to be validated.

Use 5W1H to decompose architectural problems and build a reusable “weapon‑library” of solutions.

Incorporate multiple perspectives (business, technical, user) to improve cross‑team collaboration.

Architecture Definition

Software architecture is a collection of abstract patterns that guide the design of large systems, aiming to manage complexity, reduce cost, and improve efficiency. Business systems can be classified by timing:

In‑process (real‑time) business : e‑commerce, stock trading—requires sub‑millisecond latency.

Post‑process (analytics) business : data aggregation, reporting, mining.

Pre‑process (predictive) business : recommendation, forecasting, AI‑driven decision support.

Architecture Purposes

Typical architectural goals include:

High concurrency handling (e.g., >10 k QPS).

Low latency (e.g., 95th‑percentile ≤200 ms).

High availability (four‑9s or five‑9s uptime).

Security (authentication, encryption, least‑privilege).

Scalability (horizontal scaling, sharding).

Cost efficiency (resource utilization, cloud‑native pricing).

Meeting these goals requires quantitative evaluation, not just checklist compliance.

Evaluation Metrics (SLA)

A Service‑Level Agreement (SLA) provides concrete thresholds for system health:

Availability : target uptime (e.g., 99.99 %).

Error rate : errors / total_requests.

Throughput : QPS/TPS capacity.

Latency : response‑time percentiles (p95, p99).

These metrics drive iterative improvements and serve as decision criteria for architecture upgrades.

Common Architecture Techniques

Single‑Machine Performance

Understand the C10K problem and use event‑driven I/O (epoll, kqueue) to handle many connections.

Distinguish I/O‑bound vs. CPU‑bound workloads and allocate resources accordingly.

Know the storage hierarchy (CPU cache → RAM → SSD → HDD → network) to minimize latency.

Cluster & High‑Availability

Load balancing: Nginx, cloud SLB, LVS/F5.

Stateless service design to simplify horizontal scaling.

Service decomposition into gateway, business logic, data, and storage layers.

Language/framework choices: Node.js (event‑loop), Go (goroutines), Java (JVM ecosystem), C++ (high‑performance).

Caching solutions: Redis, Codis, Redis Cluster.

Message queues: Kafka, RocketMQ.

High‑Availability Practices

Redundant deployment of service instances.

Caller‑side timeouts and retry policies.

Idempotent service interfaces to tolerate retries.

Health monitoring and alerting pipelines.

Service registry for state notification (e.g., Consul, Eureka).

Intelligent routing, circuit breaking, graceful degradation.

Elastic scaling with Docker + Kubernetes.

Storage Technologies

Relational DB: MySQL, TiDB (NewSQL, automatic sharding).

NoSQL: Elasticsearch, MongoDB.

Big‑data stores: HDFS, HBase, OpenTSDB (time‑series).

In‑memory DB: Redis (including cluster mode).

Persistent message queues: Kafka, RocketMQ.