Technical Architecture Design Principles: Strategy, Tactics, and Practical Guidelines

Hello, I am a senior architect.

Technical architecture is the process of turning product requirements into technical implementations. It addresses pure technical layering, framework and language selection (primarily Java), and non‑functional concerns such as security, performance, and big data.

The biggest challenge in technical architecture is uncertainty: whether to adopt the latest industry technologies or the ones the team is most familiar with, how to handle problems with new technologies, and how to evolve the architecture over time.

Because business requirements constantly change and technologies evolve rapidly, there is no universal architecture pattern that fits every system. To achieve a stable and excellent system, we must follow both strategic and tactical design principles.

Strategic Layer Design Principles

1. Suitability Principle – Choose the most appropriate technology rather than the newest. Over‑ambitious adoption of cutting‑edge tools often leads to failure due to limited manpower, short project cycles, and lack of accumulated experience.

2. Simplicity Principle – Keep the design as simple as possible. Complex structures increase the probability of component failures and make changes cascade across many dependent modules.

3. Evolution Principle – Treat architecture as an evolving artifact. Design for the current business needs, iterate based on real‑world feedback, retain good decisions, fix defects, discard useless parts, and adapt the architecture when business changes.

Tactical Layer Design Principles

1. High Concurrency Principle – Design for statelessness, service decomposition, message queues, data heterogeneity, and caching to enable horizontal scaling.

Stateless applications facilitate horizontal scaling.

Configuration centers can provide stateless configuration.

2. High Availability Principle – Implement degradation switches, multi‑level read services, front‑end traffic shaping (e.g., Nginx+Lua), and business‑level degradation to ensure core functionality remains available under load.

Centralized management of degradation switches.

Read‑only local cache fallback for degraded services.

Use Nginx+Lua for traffic diversion and gray‑release strategies.

3. Business Design Principle – Ensure idempotency, anti‑duplicate design, clear process definitions, state machines, feedback mechanisms, approval workflows, documentation, and backup strategies.

Technical Architecture Diagrams

Technical architecture diagrams visualize the system’s technical solution and component choices. Two main types exist:

Logical Architecture Diagram (functional requirements) – shows how technical components realize product features.

Physical Architecture Diagram (non‑functional requirements) – shows how components are physically deployed, including network, cluster, middleware, and storage design.

Logical diagrams are built in three steps: overall view, detailed sub‑system view, and final integrated view.

Overall view example:

Sub‑system detail example (real‑time, near‑real‑time, offline engines) highlighting RuleEngine and Blink for stream processing.

Integrated overall diagram showing interactions via service interfaces, databases, caches, and message queues.

Physical architecture diagram emphasizes network topology, cluster layout, middleware, and storage deployment.

Conclusion

The article provides strategic and tactical principles for business, product, data, application, and technical architecture design, helping architects plan and evolve systems effectively. Good architecture is designed, not merely emergent; it must balance planning with evolution within the software lifecycle.

Author: Hu Bin, senior technical expert at Cainiao Network, experienced in large‑scale distributed systems, big data, and architecture.