Architecture · 07 · System Architecture

01

What is it?

Software architecture is the set of important choices that shape how a system is divided, connected, operated, and changed.

It describes the system at a level above individual functions or screens. Architecture gives each major part a responsibility, defines how parts communicate, decides where data lives, and makes failure and growth visible before they become surprises.

Architecture is not one diagram frozen forever. It is a set of decisions and trade-offs that should support the product’s users, business goals, delivery pace, reliability needs, and expected change.

02

Think of it like...

Think of architecture like a city plan.

A city plan decides where homes, roads, hospitals, warehouses, and power lines go, how traffic moves between them, and what happens when one road is blocked. It does not specify every brick, but it strongly affects what the city can support and how easily it can grow.

Product manager translation

“Which parts must change independently, what must happen in real time, and what is the acceptable experience when a dependency is slow or unavailable?”

Product Need

Architecture Decisions

System Behavior

User Experience

03

What does it do?

Define responsibilities

Make it clear which component owns a capability, rule, or piece of data.

Shape communication

Choose APIs, direct calls, queues, or events for work moving between parts.

Control data flow

Show where data is created, read, changed, cached, copied, and retained.

Enable scaling

Give busy parts room to handle more traffic, users, jobs, or stored data.

Contain failure

Reduce the blast radius when a service, provider, network, or database has a problem.

Make change safer

Use boundaries and contracts so one team can evolve a part without breaking everything.

Trade-off:

Every boundary can improve ownership and independent change, but it also adds contracts, latency, monitoring, deployment work, and more ways for a request to fail. The best architecture is fit for the product’s constraints, not the most fashionable diagram.

04

Where is it used?

Architecture matters anywhere a product has more than one meaningful part or must operate reliably over time.

Web and mobile products

Connect clients, APIs, backend capabilities, data stores, and user-facing responses.

Commerce and payments

Separate checkout, inventory, payment, order records, and notifications with clear failure behavior.

Data and AI platforms

Move data through ingestion, processing, storage, retrieval, model calls, and evaluation.

Internal enterprise tools

Coordinate identity, permissions, workflows, audit records, and integrations across teams.

High-traffic events

Plan for spikes, queues, caching, capacity limits, and graceful degradation.

Long-lived systems

Protect teams from accidental coupling when the product, organization, or providers change.

05

Example

Flash-sale checkout for an online store

A product team expects a limited-time sale to bring ten times normal traffic. The architecture must keep browsing responsive, prevent overselling, take payment safely, and finish order follow-up even if email is temporarily unavailable.

Customer

Web / Mobile Client

API Gateway

Checkout Service

Inventory + Payment

Fast path

Product pages can use a cache so many shoppers do not repeatedly query the catalog database.

Safe purchase

Checkout checks inventory and payment through explicit contracts before confirming the order.

Async follow-up

An order-confirmed event lets notification and analytics work continue without holding the customer request open.

Failure behavior

If email is down, the order can remain confirmed while notification retries from a queue.

Customer → API Gateway → Checkout Service
                         ├→ Inventory Service → Database
                         ├→ Payment Provider
                         └→ OrderConfirmed event → Queue → Notifications

The architecture makes the product promise concrete: what is synchronous, what can wait, where the source of truth lives, and which failures should be retried or shown to the user.

06

How it connects

A system architecture usually connects user-facing entry points to capabilities, data, and operating infrastructure. The connection can be direct and synchronous or message-based and asynchronous.

Client

Gateway / Route

Services

Data + Events

Infrastructure

Synchronous

The caller waits for a result, such as a price quote or payment decision. It is simple to understand, but latency and dependency failures reach the user quickly.

Asynchronous

A message or event lets work continue later, such as sending an email after an order is confirmed. It improves resilience, but introduces queues, retries, and eventual consistency.

Operational

Logs, metrics, traces, alerts, deployment controls, and access policies make the architecture operable rather than merely drawable.

07

Do Not Confuse

Architecture vs implementation

Architecture is the important shape and relationship of the system. Implementation is the detailed code and configuration that realizes it.

Architecture vs component

A component is one bounded part. Architecture is the larger arrangement of components and the rules for how they work together.

Architecture vs infrastructure

Infrastructure is the computing environment and operational foundation. Architecture also includes responsibilities, contracts, data flow, and failure behavior.

Architecture vs a flowchart

A flowchart shows one path through a process. Architecture must also explain ownership, state, scaling, security, operations, and what happens when the path breaks.

08

Topic Glossary

ENGLISH TERM	中文	SIMPLE ENGLISH	中文小白理解
Architecture	架构	The important choices that organize and connect a software system.	决定软件系统如何分工、连接、扩展和应对故障的重要设计。
Component	组件	A bounded part of a system with a clear responsibility.	系统中负责一件明确工作的一个部分。
Boundary	边界	The line that separates one responsibility from another.	把不同职责分开的界线。
Interface	接口	The defined way one part asks another part to do work.	一个部分请求另一个部分做事的约定方式。
Data Flow	数据流	The path data takes as it is created, changed, stored, and read.	数据产生、变化、保存和读取时经过的路径。
Dependency	依赖	A system part or provider that another part needs.	一个系统部分必须依靠的另一个部分或外部服务。
Scaling	扩展	Changing capacity so a system can handle more or less demand.	调整系统能力，让它能承受更多或更少的需求。
Failure Handling	故障处理	The way a system responds when a part is slow, unavailable, or incorrect.	系统某部分变慢、不可用或出错时如何应对。
Trade-off	权衡	A choice that improves one quality while making another more costly or difficult.	提升一个方面、同时让另一个方面变得更贵或更难的取舍。
Source of Truth	事实来源	The place the system trusts as the authoritative version of data.	系统认定为某项数据最可靠版本的地方。

09

What to Remember

Architecture is the system’s shape: who owns what, how parts communicate, where data moves, how capacity grows, and how the product behaves when something fails.

PM Perspective

When reviewing an architecture, ask: Which user promise does each decision protect? What is the source of truth? Which dependency can become a bottleneck? What happens when it is slow or down? Which parts need to scale independently? What new operating cost or team ownership does the design create?