Mastering Software Architecture: Strategic & Tactical Design Principles

Technical architecture transforms product requirements into technical implementations, covering layering, framework selection, language (Java), and non-functional concerns such as security, performance, and big data.

The biggest challenge is uncertainty: choosing latest technologies vs familiar ones, handling problems, and future evolution.

There is no universal architecture pattern; we provide strategic and tactical design principles.

Strategic Layer Design Principles

The strategic principles are: appropriateness, simplicity, evolution.

1.1 Appropriateness Principle

Engineers often want to adopt the newest technologies, but chasing novelty without sufficient resources leads to high failure risk. Common pitfalls include insufficient manpower, lack of accumulated experience, and assuming newer technology automatically solves problems. The rule is to choose the most suitable technology for the team and project.

1.2 Simplicity Principle

Complex designs are not always better; simple solutions that meet requirements quickly are preferable. System complexity can be structural (many components, intricate relationships) or logical (complex component logic). Reducing component count improves reliability; excessive complexity harms stability and maintainability.

1.3 Evolution Principle

Software architecture must evolve with business needs, unlike static building architecture. Designing a final, unchangeable architecture leads to over‑investment and long cycles; instead, architecture should be iteratively refined, preserving valuable designs and discarding flawed ones.

Tactical Layer Design Principles

The tactical principles are divided into three parts: high concurrency, high availability, and business design.

2.1 High Concurrency Principle

Key aspects: statelessness, splitting, service‑orientation, message queues, data heterogeneity, caching.

Stateless applications facilitate horizontal scaling.

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

Service‑oriented evolution progresses from in‑process services to remote services, cluster registration, and governance.

Message queues decouple services, enable asynchronous processing, and provide traffic buffering.

Data heterogeneity stores data changes via queues and creates closed‑loop storage.

Caching spans user, proxy, access, application, and data layers (DNS, browser, CDN, Redis, etc.).

2.2 High Availability Principle

Includes degradation, rate limiting, and rollback.

Centralized degradation switches and multi‑level read services allow graceful fallback.

Rate limiting prevents malicious traffic and protects system peaks, using Nginx limits, IP deny, etc.

Rollback enables quick revert to a stable version when a deployment fails.

2.3 Business Design Principle

Idempotent and anti‑duplicate design.

Process definition and state machines.

Feedback for backend operations and approval workflows.

Documentation, backup, and clear annotations.

Technical Architecture Diagrams

Logical architecture diagrams illustrate how technical components realize functional requirements; physical diagrams show network, cluster, middleware, and storage deployment.

In summary, the article provides strategic and tactical guidance for designing stable, high‑performing systems, emphasizing that good architecture is both planned and evolved.