Strategic and Tactical Design Principles for Technical Architecture

Technical architecture transforms product requirements into concrete technical implementations, addressing layer separation, framework and language choices (primarily Java), and non‑functional concerns such as security, performance, and big data.

The biggest challenge in architecture is uncertainty: whether to adopt the latest technologies or stick with familiar ones, and how to handle future evolution.

Because business and technology constantly evolve, there is no universal architecture pattern; therefore, we propose design principles at both strategic (top‑level) and tactical (detailed) layers.

Strategic Layer Design Principles

The strategic layer follows three principles: suitability, simplicity, and evolution.

1.1 Suitability Principle

Choosing the most appropriate technology rather than the newest one reduces risk; teams should evaluate technical feasibility, resource constraints, and long‑term maintainability before adopting cutting‑edge solutions.

1.2 Simplicity Principle

Systems should be as simple as possible while meeting requirements; unnecessary complexity increases failure probability and maintenance cost.

1.3 Evolution Principle

Software architecture must evolve with business needs; designs should allow incremental improvements, removal of flawed components, and reuse of valuable lessons.

Tactical Layer Design Principles

The tactical layer is divided into three parts: high‑concurrency, high‑availability, and business design.

2.1 High‑Concurrency Principle

Key aspects include statelessness, service decomposition, service‑oriented design, message queues, data heterogeneity, and caching.

Stateless services enable horizontal scaling.

Decomposition can be done by system, function, read/write, AOP, or module dimensions.

Service‑oriented evolution progresses from in‑process services to remote services, then to cluster‑managed services with registration, discovery, grouping, isolation, routing, and governance.

Message queues decouple services, provide asynchronous processing, traffic buffering, and ensure eventual consistency.

Data heterogeneity stores changed data in a separate store to form a closed loop.

Caching spans user‑side (DNS, browser, app), proxy‑side (CDN, Nginx), access‑side (Nginx proxy_cache, Nginx+Lua+Redis), application‑side (static pages, Redis/Memcached), and data‑side (NoSQL).

2.2 High‑Availability Principle

Includes degradation (centralized switch management, multi‑level read services, Nginx+Lua routing, business‑level degradation) and rate‑limiting (protecting against malicious traffic, using Nginx limits, IP deny lists, iptables).

2.3 Business Design Principle

Idempotent design

Avoid duplicate operations

Define clear workflows and state machines

Provide feedback for backend operations

Implement approval processes and documentation

Ensure backup and recovery

Technical Architecture Diagrams

Two types of diagrams are used:

Logical architecture diagram (functional requirements) – shows how technical components realize product features.

Physical architecture diagram (non‑functional requirements) – depicts network, cluster, middleware, and storage deployment.

Conclusion

Good software architecture is planned, not merely emergent; a solid initial design simplifies later evolution, improves performance and quality, and reduces the difficulty of future changes, much like city planning.

Author: Hu Bin, technical expert at Cainiao Network, responsible for the Cainiao risk control system, with extensive experience in large‑scale distributed applications, big data, and architecture.