Strategic and Tactical Design Principles for Technical Architecture

Technical architecture transforms product requirements into technical implementations, covering layering, framework and language choices (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 the team’s familiar stack, and how to handle future evolution.

Strategic design principles (top‑level) are the suitability principle, simplicity principle, and evolution principle.

1.1 Suitability Principle – Choose the most appropriate technology rather than the newest; avoid over‑ambitious projects that exceed team capacity or expertise.

Insufficient manpower for excessive work.

Lack of accumulated knowledge prevents “one‑step” breakthroughs.

New technologies are not universally better; select the most suitable.

1.2 Simplicity Principle – Prefer simple, maintainable solutions over overly complex designs; understand structural and logical complexity.

Structural complexity arises from many components and intricate relationships, leading to lower availability and cascading failures. Logical complexity occurs when a single component implements too many functions.

1.3 Evolution Principle – Treat architecture as an evolving artifact; design for current needs, iteratively improve, and refactor as business changes.

Tactical design principles focus on high concurrency, high availability, and business design.

2.1 High‑Concurrency Principle – Emphasize statelessness, service decomposition, messaging, data heterogeneity, and caching.

Stateless services enable horizontal scaling.

Split systems by function, feature, read/write patterns, AOP, or module.

Service‑oriented evolution from in‑process to cluster‑wide services.

Use message queues for decoupling and traffic buffering.

Adopt data heterogeneity for flexible storage.

Apply caching at user, proxy, access, application, and data layers.

2.2 High‑Availability Principle – Implement degradation switches, multi‑level read services, Nginx/Lua based traffic shaping, and business‑level degradation.

Apply rate‑limiting to protect against abusive traffic using Nginx limits, IP deny lists, or firewall rules.

Ensure rollback capability to revert to a stable version quickly.

2.3 Business Design Principles – Avoid redesign, ensure idempotency, define processes, use state machines, provide feedback and approval flows, document code, and maintain backups.

Technical architecture diagrams (logical and physical) visualize component relationships, deployment, and data flow. Logical diagrams show how functional requirements map to technology components; physical diagrams depict network, cluster, middleware, and storage topology.

In conclusion, good software architecture requires careful planning, simplicity, suitability, and continuous evolution to support business growth.