Mastering Technical Architecture: Strategic & Tactical Design Principles

What is Technical Architecture?

Technical architecture is the process of turning product requirements into technical implementations, defining the components, their relationships, and deployment strategies.

Key Challenges

The biggest challenge is uncertainty: deciding between the latest technologies and those familiar to the team, handling future evolution, and mitigating risks associated with new or untested solutions.

Strategic Layer Design Principles

Fit Principle

Select technology that best fits the team’s capabilities and project needs rather than chasing the newest hype.

Limited personnel cannot support many new technologies simultaneously.

Lack of experience increases failure probability.

Technology should address specific scenarios, not be a universal cure.

Simplicity Principle

Prefer simple designs; avoid unnecessary complexity. Distinguish structural complexity (many components) from logical complexity (intricate logic).

Structural complexity raises failure probability and creates cascading impacts when a component changes. Logical complexity can make a single component too intricate to maintain.

Evolution Principle

Architecture must evolve with business needs; avoid one‑off “perfect” designs. Iterate, retain valuable parts, fix defects, and adapt when the business changes.

Tactical Layer Design Principles

High Concurrency

Design for high‑throughput systems by considering statelessness, splitting, service‑orientation, message queues, data heterogeneity, and caching.

Stateless applications enable horizontal scaling.

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

Service‑oriented evolution: in‑process → remote → cluster with registration, discovery, grouping, isolation, routing, and governance.

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

Data heterogeneity: ingest changes via queues, store in heterogeneous stores, and form closed‑loop data pipelines.

Caching at multiple layers: user (DNS, browser, OS), proxy (CDN), access (Nginx proxy cache), application (static pages, Redis/Memcached), and data (NoSQL).

High Availability

Incorporate downgrade mechanisms, rate limiting, and rollback capabilities.

Centralized feature‑toggle management for graceful degradation.

Multi‑level read services that fallback to local cache.

Nginx+Lua for traffic steering and gray releases.

Business‑level degradation to keep core functions during spikes.

Rate limiting to protect against abusive traffic and overload.

Rollback to the previous stable version if a deployment fails.

Business Design Principles

Anti‑duplicate and idempotent designs.

Clear workflow definitions and state‑machine modeling.

Feedback mechanisms for backend operations.

Approval processes and thorough documentation.

Regular backups.

Technical Architecture Diagrams

Two diagram types are used: logical (functional) diagrams that map components to product features, and physical (non‑functional) diagrams that depict network, cluster, middleware, and storage deployment.

Logical diagrams follow an overall‑partial‑overall approach, detailing each subsystem’s technology stack (e.g., caching, messaging, stream processing). Physical diagrams focus on hardware placement, network topology, and resource allocation.

Conclusion

Architecture should begin with strategic principles—fit, simplicity, evolution—and be refined through tactical practices covering concurrency, availability, and business design. Balancing careful planning with continuous evolution yields stable, high‑performing systems that can adapt to changing business demands.