Bagaimana komponen berkomunikasi dalam sesuatu sistem (API)?

Question

Accepted Answer

Dalam sesuatu sistem, komponen (perkhidmatan, klien) berkomunikasi melalui **API** dan pelbagai protokol — segerak (REST, gRPC) dan tak segerak (pemesejan/baris gilir). Memahami cara komponen berkomunikasi adalah asas kepada mereka bentuk sistem yang terdiri daripada berbilang bahagian.

## Komunikasi segerak (permintaan/respons)

```text
The caller WAITS for a response (blocking):
  REST (HTTP) → most common; resources over HTTP (JSON) → simple, ubiquitous, web-friendly
  gRPC → high-performance RPC (binary, HTTP/2) → fast, typed; good for internal services
  GraphQL → flexible queries (client requests exactly what it needs)
→ for: direct request/response where the caller needs an answer now
```

## Komunikasi tak segerak (pemesejan)

```text
The caller does NOT wait (decoupled, non-blocking):
  MESSAGE QUEUES (RabbitMQ, SQS) → send a message; a consumer processes it later
  EVENT STREAMING (Kafka) → publish events; consumers react
  PUB/SUB → broadcast events to subscribers
→ for: decoupling, background work, handling spikes, event-driven systems
  ✓ resilience (queue buffers), scalability, decoupling  ✗ more complexity, eventual consistency
```

## Memilih dan pertimbangan

```text
SYNC → when the caller needs an immediate response; simpler request/response
ASYNC → when decoupling, resilience, or background processing matters (don't block)
→ Also: API design (clear contracts), versioning, error handling, timeouts/retries,
  authentication, rate limiting → robust communication between components
```

## Mengapa ia penting

Memahami cara komponen berkomunikasi melalui API adalah asas kerana **sistem terdiri daripada berbilang bahagian yang mesti berkomunikasi**, jadi memahami komunikasi adalah penting untuk mereka bentuknya.

Sistem terdiri daripada perkhidmatan dan klien yang berinteraksi, dan cara mereka berkomunikasi ialah aspek asas dalam reka bentuk sistem.

Memahami **komunikasi segerak** (permintaan/respons di mana pemanggil menunggu) — **REST** (pendekatan HTTP/JSON yang tersebar luas), **gRPC** (RPC berprestasi tinggi untuk perkhidmatan dalaman), dan GraphQL (pertanyaan fleksibel) — merangkumi cara lazim komponen membuat panggilan terus sambil mengharapkan jawapan.

Memahami **komunikasi tak segerak** (terpisah, tanpa sekatan) — **message queue** (menghantar mesej untuk diproses kemudian), **event streaming** (Kafka), dan pub/sub — adalah sama pentingnya, kerana ia membolehkan **pemisahan, daya tahan (baris gilir menampan beban), skalabiliti, dan sistem dipacu peristiwa**, dengan kos kerumitan yang lebih tinggi dan ketekalan eventual.

Memahami **perbezaan segerak vs tak segerak dan bila menggunakan setiap satu** — segerak apabila pemanggil memerlukan respons segera, tak segerak apabila pemisahan, daya tahan, atau pemprosesan latar belakang penting — ialah pertimbangan reka bentuk utama yang ketara mempengaruhi ciri-ciri sesebuah sistem.

Memahami pertimbangan tambahan (kontrak API yang jelas, versioning, pengendalian ralat, timeout/retry, pengesahan, rate limiting) mencerminkan reka bentuk komunikasi yang teguh.

Memandangkan sistem terdiri daripada bahagian yang berkomunikasi dan cara mereka berkomunikasi (segerak vs tak segerak, protokol, dan pertimbangan reka bentuk) membentuk sistem secara asas, dan memandangkan memahami komunikasi komponen adalah penting untuk mereka bentuk sistem berbilang komponen, memahami cara komponen berkomunikasi melalui API adalah pengetahuan reka bentuk sistem yang penting dan asas — asas kepada mereka bentuk sistem yang terdiri daripada berbilang bahagian yang berinteraksi, merangkumi komunikasi segerak dan tak segerak yang menghubungkan komponen, serta teras kepada seni bina sistem teragih berasaskan perkhidmatan yang lazim hari ini.