Mastering Software Architecture: Strategic & Tactical Design Principles

Technical architecture translates product requirements into concrete implementations, addressing layering, framework, language (Java), and non‑functional concerns such as security, performance, and big data.

Strategic Design Principles

Architects face uncertainty: choosing the latest technology versus familiar tools, handling future evolution, and balancing risk.

Appropriateness Principle

Choosing the most suitable technology over the newest; avoid over‑committing resources to unproven frameworks, consider team size, project timeline, and existing expertise.

Limited manpower cannot support many new technologies.

Insufficient accumulated knowledge makes “building the next big thing” unrealistic.

New tech is not automatically better; select the best fit for the scenario.

Simplicity Principle

Simpler solutions that meet requirements quickly are preferred; complexity adds maintenance risk. Structural complexity (many components) reduces reliability, while logical complexity (over‑engineered code) hampers scalability.

Example: a system with many components sees compounded failure probability; reducing components improves availability.

Evolution Principle

Software architecture must evolve with business needs, unlike static building architecture. Design iteratively: deliver an initial solution, refine based on feedback, and rewrite or extend when requirements change.

Tactical Design Principles

High Concurrency Principle

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

Stateless : facilitates horizontal scaling.

Splitting : by system, function, read/write, AOP, module.

Service‑orientation : evolution from in‑process to clustered services with discovery and governance.

Message queues : decouple services, enable async processing, buffer spikes, ensure eventual consistency.

Data heterogeneity : ingest changes via queues, store atomically, create closed‑loop data flow.

Caching : layered caches at user, proxy, access, application, and data layers (DNS, CDN, Redis, etc.).

High Availability Principle

Techniques include degradation switches, multi‑level read services, Nginx+Lua based traffic shaping, and graceful fallback to core functions under load.

Rate limiting protects against abusive traffic, using Nginx limits, IP deny rules, or firewall policies.

Rollback capability ensures rapid revert to a stable version if deployment fails.

Business Design Principle

Guidelines such as idempotency, anti‑duplicate design, workflow definition, state machines, feedback mechanisms, approval processes, documentation, and backup strategies.

Technical Architecture Diagrams

Two diagram types: logical (functional) architecture showing component interactions, and physical (non‑functional) architecture illustrating deployment, network, clustering, middleware, and storage.

Logical diagram example: overall application distribution, followed by detailed subsystem views (e.g., real‑time, offline, near‑real‑time engines with specific technologies).

Physical diagram example: network topology, cluster layout, middleware placement, and data storage design, revealing the system’s runtime organization.

Conclusion

Good software architecture is both planned and evolved; solid initial design reduces future refactoring effort, while continuous iteration adapts to changing business needs, ensuring performance, quality, and maintainability throughout the system’s lifecycle.