Service · 07 · System Architecture

01

What is it?

A service is a software unit that provides a specific capability through a defined interface.

The interface tells other parts of the product what they can ask for and what kind of result they can expect. The service keeps the details of how it does the work behind that boundary.

Core definition:
A service is a software unit that provides a specific capability through a defined interface.

Capability

It does a meaningful job, such as pricing an order, sending a notification, or checking inventory.

Interface

It exposes a stable way to request that job, often an API endpoint, function, or message contract.

Boundary

It separates the caller from implementation details, so the inside can change without changing every caller.

02

Think of it like...

Think of a service like a specialist department with a public counter.

A product team does not need to know which employee, database query, or outside provider the department uses. It needs to know what request to make and what result will come back.

Product manager translation

“Who owns this capability, what can other teams ask it to do, and what happens when it is unavailable?”

Caller

Service Interface

Service Logic

Result or Event

03

What does it do?

Expose a capability

Give the rest of the system one clear way to request a business operation.

Apply rules

Check decisions such as eligibility, price, inventory, or payment status.

Coordinate work

Call repositories, external APIs, or other services in the right order.

Hide implementation

Keep callers independent from internal storage and provider details.

Return a useful result

Provide success, failure, or a clear status that the caller can act on.

Protect a boundary

Make ownership, permissions, reliability, and change impact easier to reason about.

Trade-off: a service boundary creates clarity and ownership, but it also adds contracts, testing, monitoring, and failure modes. A boundary is useful when the capability is important enough to justify that cost.

04

Where is it used?

Services appear in many architectures. The word describes a responsibility first; it does not automatically mean a separate server or a microservice.

Order and checkout

Validate an order, calculate totals, reserve stock, and create a purchase.

Payments

Authorize a payment and translate a provider response into a product decision.

Notifications

Choose a channel and send email, SMS, or in-app messages.

Identity

Verify credentials, issue sessions, or check access to a protected action.

Search and recommendations

Turn product data into a ranked result for a user or another system.

Internal platform capabilities

Offer shared files, reporting, feature flags, or audit logging through a stable interface.

05

Example

Checkout Service for an online store

When a customer presses “Place order,” the checkout service owns the workflow. The route or frontend does not need to coordinate every rule and integration itself.

Checkout request

Validate cart and stock

Authorize payment

Save order

Confirm and notify

POST /checkout
{
  "cart_id": "cart_4821",
  "payment_method": "card"
}

→ Checkout Service returns: { "status": "confirmed", "order_id": "ord_1042" }

The interface is small and predictable even though the work behind it may involve inventory, payment, order storage, and notifications.

06

How it connects

Client

API Gateway or Route

Service Interface

Service

Data or External API

Synchronous path

The caller waits for a result, such as a price quote or payment decision.

Asynchronous path

The service publishes an event, such as OrderConfirmed, and another worker handles follow-up work later.

Operational path

Logs, metrics, traces, retries, and alerts show whether the capability is healthy and dependable.

07

Do Not Confuse

Service vs component

A component is any bounded part with a responsibility. A service is a component whose responsibility is exposed as a capability for callers.

Service vs API

An API is the interface or contract. A service is the unit that provides the capability behind that interface.

Service vs microservice

A microservice is a service operated as an independently deployable process. A service can also live inside a monolith.

Service vs business logic

Business logic is the rules and decisions. A service is the boundary and coordinator that can contain or call those rules.

08

Topic Glossary

ENGLISH TERM	中文	SIMPLE ENGLISH	中文小白理解
Service	服务	A software unit that provides a specific capability through an interface.	通过接口提供某项具体能力的软件单元。
Service Interface	服务接口	The defined way a caller asks a service to do work.	调用方请求服务执行工作的明确方式。
Service Boundary	服务边界	The line separating a service's responsibility from its callers.	把服务负责的事情和调用方分开的界线。
Capability	能力	A useful operation that a service can provide.	服务可以提供的一项有用操作。
Contract	契约	The expected inputs, outputs, and behavior between systems.	系统之间约定好的输入、输出和行为。
Service Layer	服务层	A layer that coordinates application operations.	集中协调应用操作的一层。
Microservice	微服务	A service deployed and operated as an independent unit.	作为独立单元部署和运行的服务。
Synchronous	同步	The caller waits for the service response.	调用方等待服务返回结果。
Asynchronous	异步	The service continues through a message or event without making the caller wait.	服务通过消息或事件继续处理，不让调用方一直等待。
Service Ownership	服务所有权	Responsibility for a service's behavior, reliability, and change.	对服务的行为、可靠性和变更负责。

09

What to Remember

A service turns one important capability into a clear, reusable boundary.

Its interface is the promise; its implementation can coordinate rules, data, other services, and external systems behind the promise.

PM Perspective

When a team proposes a new service, ask: What capability is being isolated? Who owns the contract? Which users or products depend on it? What latency, failure, data, and operating cost does the boundary introduce?