Essential Architecture Terms Every Architect Should Know

ROI

ROI (Return on Investment) is calculated as profit divided by total investment, expressed as a percentage. It helps architects decide whether a technical or project decision is worthwhile. For example, spending a month improving a simple customer‑service system that does not boost retention or efficiency yields an ROI below 1, indicating low value. The article notes ROI’s limitation: it lacks a global view and ignores hidden returns such as downstream revenue from marketing campaigns.

SOLID Principles

The five SOLID design principles are presented:

Single Responsibility Principle (SRP) : a class should have only one responsibility.

Open/Closed Principle (OCP) : software entities should be open for extension but closed for modification.

Liskov Substitution Principle (LSP) : derived classes must be substitutable for their base classes without breaking functionality.

Interface Segregation Principle (ISP) : clients should not be forced to depend on interfaces they do not use.

Dependency Inversion Principle (DIP) : high‑level modules should depend on abstractions, not concrete low‑level modules.

The article explains how these principles interrelate, with SRP as the foundation, OCP as the ultimate goal, LSP supporting OCP, ISP reinforcing LSP and SRP, and DIP guiding ISP.

Splitting and Decoupling

Splitting (vertical or horizontal) is used for organization restructuring, code security, replaceability, delivery speed, technical constraints, and business requirements. Vertical splitting separates systems by business domains, while horizontal splitting separates by technical layers to improve reuse. The article lists concrete motivations such as team growth, protecting core algorithms, enabling modular customization, reducing regression testing effort, and supporting high‑availability or performance needs.

Isolation Thinking

Isolation is likened to ship compartments: if one compartment is damaged, others remain functional. In distributed systems, isolation can be achieved via system isolation (deploying modules on separate machines, separating storage and access layers) and user isolation (routing different users to distinct instances, as done by large internet companies). Isolation reduces resource contention and clarifies system boundaries.

ACID

ACID defines four transaction properties:

Atomicity : a transaction is all‑or‑nothing.

Consistency : the database moves from one consistent state to another.

Isolation : intermediate changes are invisible to other transactions; isolation levels range from read‑uncommitted to serializable, with higher levels reducing concurrency performance.

Durability : once committed, changes survive crashes.

The article urges architects to keep ACID in mind when designing reliable systems.

CAP and BASE

CAP theorem states that a distributed system can only simultaneously guarantee two of three properties: Consistency, Availability, and Partition tolerance. Architects must trade off between CP (strong consistency, possible reduced availability) and AP (high availability, eventual consistency). BASE (Basically Available, Soft state, Eventually consistent) is presented as a practical response to CAP, sacrificing strict consistency for availability.

Distributed Transactions

When monolithic applications split into services, traditional ACID no longer applies, prompting the need for distributed transaction solutions. The article outlines the DTP model from X/Open, the XA protocol steps (resource manager connections, global transaction ID registration, prepare phase, commit/rollback decision), and mentions two‑phase commit (2PC), three‑phase commit (3PC), and TCC as implementation options.

System Capacity Estimation

Capacity planning involves estimating QPS, PV, UV, bandwidth, and concurrency. Formulas are provided, e.g., QPS = total_requests / (processes * time), bandwidth = (PV × page_size × 8) / time, and concurrency = (PV × avg_connections_per_page) / (time × server_count). Example calculations illustrate average and peak bandwidth (3.7 Mbps average, 18.5 Mbps peak) and concurrency (average 35, peak 210) for a site with given traffic figures.

Conclusion

The article summarizes that mastering these architectural terms expands a technologist’s perspective, enabling better design decisions and deeper understanding of system trade‑offs.