Các thành phần trong một hệ thống giao tiếp với nhau như thế nào (APIs)?

Question

Accepted Answer

Trong một hệ thống, các thành phần (service, client) giao tiếp qua **APIs** và nhiều protocol — đồng bộ (REST, gRPC) và bất đồng bộ (messaging/queues). Hiểu cách các thành phần giao tiếp là điều cơ bản để thiết kế những hệ thống gồm nhiều phần.

## Giao tiếp đồng bộ (request/response)

```text
Bên gọi CHỜ một phản hồi (blocking):
  REST (HTTP) → phổ biến nhất; tài nguyên qua HTTP (JSON) → đơn giản, phổ cập, thân thiện web
  gRPC → RPC hiệu năng cao (binary, HTTP/2) → nhanh, có kiểu; tốt cho service nội bộ
  GraphQL → query linh hoạt (client yêu cầu chính xác cái nó cần)
→ cho: request/response trực tiếp khi bên gọi cần câu trả lời ngay
```

## Giao tiếp bất đồng bộ (messaging)

```text
Bên gọi KHÔNG chờ (decoupled, non-blocking):
  MESSAGE QUEUES (RabbitMQ, SQS) → gửi một message; một consumer xử lý nó sau
  EVENT STREAMING (Kafka) → publish event; các consumer phản ứng
  PUB/SUB → broadcast event tới các subscriber
→ cho: decoupling, công việc nền, xử lý đợt tăng đột biến, hệ thống event-driven
  ✓ resilience (queue làm buffer), scalability, decoupling  ✗ phức tạp hơn, eventual consistency
```

## Lựa chọn và cân nhắc

```text
SYNC → khi bên gọi cần phản hồi ngay lập tức; request/response đơn giản hơn
ASYNC → khi decoupling, resilience, hoặc xử lý nền quan trọng (đừng block)
→ Ngoài ra: thiết kế API (contract rõ ràng), versioning, xử lý lỗi, timeout/retry,
  authentication, rate limiting → giao tiếp vững chắc giữa các thành phần
```

## Tại sao điều này quan trọng

Hiểu cách các thành phần giao tiếp qua API là nền tảng vì **hệ thống gồm nhiều phần phải giao tiếp với nhau**, nên hiểu giao tiếp là thiết yếu để thiết kế chúng.

Hệ thống gồm các service và client tương tác với nhau, và cách chúng giao tiếp là một khía cạnh cơ bản của system design.

Hiểu **giao tiếp đồng bộ** (request/response nơi bên gọi chờ) — **REST** (cách tiếp cận HTTP/JSON phổ cập), **gRPC** (RPC hiệu năng cao cho service nội bộ), và GraphQL (query linh hoạt) — bao quát các cách phổ biến để các thành phần gọi trực tiếp và mong đợi câu trả lời.

Hiểu **giao tiếp bất đồng bộ** (decoupled, non-blocking) — **message queues** (gửi message để xử lý sau), **event streaming** (Kafka), và pub/sub — cũng quan trọng không kém, vì nó cho phép **decoupling, resilience (queue làm buffer tải), scalability, và hệ thống event-driven**, với cái giá là phức tạp hơn và eventual consistency.

Hiểu **sự phân biệt sync vs async và khi nào dùng cái nào** — đồng bộ khi bên gọi cần phản hồi ngay, bất đồng bộ khi decoupling, resilience hoặc xử lý nền quan trọng — là một cân nhắc thiết kế then chốt ảnh hưởng đáng kể đến đặc tính của hệ thống.

Hiểu các cân nhắc bổ sung (contract API rõ ràng, versioning, xử lý lỗi, timeout/retry, authentication, rate limiting) phản ánh việc thiết kế giao tiếp vững chắc.

Vì hệ thống gồm các phần giao tiếp với nhau và cách chúng giao tiếp (sync vs async, các protocol, và các cân nhắc thiết kế) định hình hệ thống một cách cơ bản, và vì hiểu giao tiếp giữa các thành phần là thiết yếu để thiết kế hệ thống nhiều thành phần, nên hiểu cách các thành phần giao tiếp qua API là kiến thức system design thiết yếu, nền tảng — cơ bản để thiết kế hệ thống gồm nhiều phần tương tác, bao quát giao tiếp đồng bộ và bất đồng bộ nối kết các thành phần, và trung tâm của việc kiến trúc những hệ thống phân tán, dựa-trên-service phổ biến ngày nay.