Mastering Software Architecture: 15 Universal Principles, Common Pitfalls, and Evolution from Monolith to Microservices

1. Architecture = Elements + Structure + Connection

In software engineering, "architecture" is defined as the combination of essential elements (sub‑systems, modules, components), their structural arrangement, and the connections between them.

1.1 System and Sub‑system

A system is a group of related entities that work together according to defined rules to achieve capabilities that individual parts cannot provide. Key concepts include association , rules , and ability . A sub‑system is a system that exists as a part of a larger system.

1.2 Module and Component

A module is a logical unit obtained by decomposing a system; a component is a physical unit (e.g., service, database, MQ, container). Modules focus on responsibility separation, while components emphasize reuse.

1.3 Framework vs. Architecture

A framework provides a set of conventions and basic functions (e.g., MVC, Spring, Django) to help implement a specific set of standards. An architecture defines the overall structure and relationships of the system; the framework is the "norm", the architecture is the "structure".

2. Is There No Architecture Design? Maybe Your System Is Not Complex Enough

When a system is simple, a monolithic application may suffice. As business grows, the system evolves from monolith to distributed services and finally to microservices. Without proper architecture, problems such as unclear service boundaries, severe coupling, difficulty locating issues, and uncontrolled technology stacks arise.

3. Different Architectures – How to Classify Them

Based on TOGAF9, architectures can be classified as:

Business Architecture : business strategy, governance, organization, key processes.

Data Architecture : logical and physical data assets and management resources.

Application Architecture : blueprint of deployed applications and their interactions.

Technical Architecture : required hardware, middleware, network, and standards.

Combining these with code and deployment perspectives yields six practical categories: business, application, data, technical, code, and deployment architecture.

4. Monolithic Application

A monolith follows a three‑tier structure (frontend + business logic + database). It is easy to deploy and test initially, but as the codebase grows, maintainability, flexibility, and scalability degrade, leading to high complexity, technical debt, low deployment frequency, and reliability issues.

5. Distributed Application

To address monolith drawbacks, the system is split into independent services deployed on separate servers. Benefits include reduced coupling, clear responsibilities, easier scaling, and better fault isolation, though it introduces higher operational overhead and distributed complexity.

6. Microservices

Microservices further decompose business logic into fine‑grained services, enabling rapid development, independent deployment, technology‑agnostic stacks, and fast iteration. Challenges include higher operational demands, inherent distributed complexity, API change costs, and potential code duplication.

7. 15 Universal Architecture Design Principles

Redundancy Design : Ensure at least one redundant instance for each service.

Rollback Design : Systems must support backward‑compatible rollbacks within a reasonable time.

Feature‑Toggle Design : Provide switches to disable any feature at runtime.

Monitoring Design : Incorporate monitoring from the design phase.

Use Mature Technologies : Prefer proven, commodity solutions over trendy, untested ones.

Fault Isolation : Avoid sharing resources and crossing isolation zones.

Horizontal Scalability : Design for X‑axis (servers), Y‑axis (databases), and Z‑axis (functional) scaling.

Buy Non‑Core Services : Leverage cloud services for non‑core capabilities.

Commodity Hardware : Use low‑cost, interchangeable hardware to enable cheap scaling.

Fast Iteration : Adopt small builds, small releases, and rapid feedback loops.

Stateless Design : Keep services stateless to simplify scaling and load balancing.

Forward‑Looking Design : Distinguish between current (Now), next‑generation (Now+1), and future (Now+2) architectural goals.

Automation : Automate building, testing, deployment, and operations.

Proactive Monitoring : Use monitoring for self‑diagnosis, auto‑recovery, capacity planning, and bottleneck detection.

Continuous Evolution : Regularly revisit and refine architecture as business evolves.

8. Six Common Architecture Design Pitfalls

High‑level designs that never materialize.

Missing critical constraints and non‑functional requirements.

Over‑designing for an uncertain future.

Making key decisions too early.

Blindly following customer demands without technical judgment.

Lacking foresight in daily development.

Ignoring system testability.

Attempting to achieve a perfect architecture in one step.

Avoid these pitfalls by involving developers in architectural discussions, iterating designs, balancing business needs with technical realities, and continuously validating assumptions.