Strategic & Tactical Design Principles for Scalable Technical Architecture

Introduction

Technical architecture translates product requirements into concrete technical implementations, covering layer separation, framework and language selection (primarily Java), and non‑functional concerns such as security, performance, and big data. The biggest challenge is uncertainty: whether to adopt the latest technologies or stick with familiar ones, and how to evolve the architecture over time.

Strategic Design Principles

The strategic layer provides high‑level methods and ideas, acting as top‑level design. It is guided by three principles:

Suitability Principle : Choose technologies that fit the team’s capabilities and project context rather than chasing the newest trends.

Simplicity Principle : Keep the system as simple as possible while meeting requirements, avoiding unnecessary complexity.

Evolution Principle : Design the architecture to evolve with business changes rather than attempting a one‑time perfect solution.

Suitability Principle Details

Developers often want to experiment with cutting‑edge frameworks or reinvent components, but doing so without sufficient resources leads to high failure risk. Common pitfalls include:

Insufficient manpower to research, build, and maintain new technologies.

Lack of accumulated experience to create industry‑leading solutions.

Assuming newer technology automatically solves all problems.

The principle emphasizes selecting the most appropriate technology for the team and project.

Simplicity Principle Details

Complexity can be structural (many components and intricate relationships) or logical (overly complicated business logic). Reducing component count lowers failure probability and improves maintainability. Simplicity follows the “less is more” philosophy.

Evolution Principle Details

Software architecture, unlike building architecture, must continuously adapt to business growth. Designing an architecture that can be iteratively refined—preserving good designs, fixing defects, and discarding obsolete parts—ensures long‑term viability.

Tactical Design Principles

The tactical layer offers concrete guidance in three areas: high concurrency, high availability, and business design.

High Concurrency Principles

Statelessness : Stateless services facilitate horizontal scaling.

Splitting : Decompose systems by function, feature granularity, read/write patterns, AOP concerns, or module layers.

Service‑orientation : Progress from in‑process calls to remote services, then to automated service discovery, grouping, isolation, routing, and governance.

Message Queues : Decouple services, enable asynchronous processing, and buffer traffic spikes.

Data Heterogeneity : Use message queues to capture data changes and store them in heterogeneous data stores, forming a data‑closed loop.

Caching : Apply caching at user, proxy, access, application, and data layers (DNS, browser, CDN, Nginx, Redis, NoSQL, etc.).

High Availability Principles

Degradation : Centralize feature‑toggle management, provide read‑only fallbacks, and use Nginx+Lua for traffic steering.

Rate Limiting : Prevent abusive traffic via cache‑only paths, Nginx limits, and IP deny rules.

Rollback : Enable rapid rollback to the previous stable version when a deployment fails.

Business Design Principles

Idempotent design

Avoid duplicate implementations

Clear process definitions

State machines for workflow control

Feedback mechanisms for backend operations

Approval workflows for administrative actions

Comprehensive documentation and comments

Regular backups

Architecture Diagrams

Technical architecture diagrams visualize system solutions and component selections. Two main types are:

Logical Architecture Diagram : Shows how technical components fulfill functional requirements.

Physical Architecture Diagram : Focuses on network, cluster, middleware, and storage design, illustrating deployment topology.

Examples (images omitted) illustrate overall system layout, detailed subsystem designs (e.g., real‑time, near‑real‑time, and offline engines in a risk‑control system), and the final integrated view.

Conclusion

The article provides a set of strategic and tactical guidelines for designing business, product, data, application, and technical architectures. It emphasizes that good architecture is both planned and evolved, and that thoughtful design and continuous iteration are essential for building high‑performance, maintainable systems.