MODULE 07 · SYSTEM ARCHITECTURE
Microservices split a system into independently owned and deployable services connected through APIs, events, or queues.
Microservices is an architectural approach where a product is made of several services, each responsible for a focused business capability and owned by a clear team.
A service has an explicit interface and release boundary. The important idea is not simply “many small programs”; it is that teams can change, deploy, and scale one capability without rebuilding the whole product. That independence also creates network, data, observability, and ownership work.
Think of a group of specialist shops that share a street but run their own staff, schedules, and tills.
Each shop can change its own operations, but the customer journey across shops needs coordination. Microservices work similarly: local autonomy trades for more coordination at the boundaries.
Teams can own a focused capability, its interface, and its operational behavior.
One service can ship without rebuilding and releasing every other service.
A busy capability can receive more instances without scaling all capabilities equally.
A degraded service does not have to make every unrelated capability unavailable.
APIs, events, and queues expose how teams and services depend on one another.
A service can use the storage or runtime that fits its business responsibility.
Microservices can fit large products with multiple teams, distinct scaling needs, or strong reasons to isolate failures. They are not automatically the right choice for a small or early product.
A retailer may run catalog, cart, checkout, payment, fulfillment, and notification as separate services. When a shopper places an order, checkout can call payment synchronously, then publish an order-created event for fulfillment and notifications.
Checkout can scale and deploy on its own, while catalog can release search improvements separately.
A failed network call, duplicate message, or incompatible contract can break a cross-service flow.
Use the boundary where team or operational independence is worth its complexity.
PM Perspective: define what the user sees when payment is slow, whether fulfillment can be eventually consistent, and who owns recovery when a dependency fails.
Services communicate through APIs, messages, or events. A distributed request may cross several processes, so timeouts, retries, duplicate handling, tracing, versioned contracts, and clear ownership become part of the product’s reliability model.
The caller waits for a result. Useful for an immediate payment decision, but latency and failure remain in the request path.
The producer announces that something happened. Useful when downstream work can happen later, but consistency may be delayed.
A worker receives buffered work. Useful for smoothing bursts and retries, but messages can be delayed or delivered more than once.
Modules inside one deployable application are not independently deployable microservices.
Data ownership can be designed in different ways; independent operation is the defining concern.
They can improve autonomy while increasing operational and coordination costs.
A service owns a capability and behavior; a table is a storage structure.
A service can deploy alone but still depend on contracts, identity, queues, data, and other services in a user workflow.
Microservices describes service boundaries; serverless describes an execution and hosting model.
| ENGLISH TERM | 中文 | SIMPLE ENGLISH | 中文小白理解 |
|---|---|---|---|
| Microservices | 微服务 | An architecture made of independently deployable services. | 把系统拆成多个可以独立发布的小服务。 |
| Service Boundary | 服务边界 | A clear line around a capability and its owner. | 划分一个能力由谁负责、怎样与外部连接的界线。 |
| Service Contract | 服务契约 | The agreed API or message shape between services. | 服务之间约定好的接口或消息格式。 |
| Event | 事件 | A signal that something happened. | 表示某件事已经发生的信号。 |
| Eventual Consistency | 最终一致性 | Different parts become consistent after some time. | 不同地方的数据不会马上一样，但过一段时间会趋于一致。 |
| Independent Deployment | 独立部署 | Release one service without releasing every service. | 只发布一个服务，不必同时发布整个系统。 |
See the Module 07 Glossary for related system architecture terms.
Microservices exchange a single application boundary for multiple independently operated service boundaries.