Bagaimana microservices saling berkomunikasi?

Question

Accepted Answer

Layanan berkomunikasi secara **synchronous** (request/response melalui REST atau gRPC) atau **asynchronous** (pesan/event melalui broker seperti Kafka atau RabbitMQ).

## Synchronous (request/response)

Pemanggil menunggu balasan. Sederhana dan intuitif, tetapi menghubungkan ketersediaan — jika yang dipanggil down, pemanggil terpengaruh.

```http
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
```

## Asynchronous (messaging/events)

Pengirim mempublikasikan pesan dan melanjutkan; konsumen memproses kemudian. Ini memisahkan layanan dalam waktu.

```text
Order Service ──publish "OrderPlaced"──▶ [ Broker ] ──▶ Email Service
                                              │
                                              └──▶ Inventory Service
```

## Kapan menggunakan yang mana

| Kebutuhan | Pilih |
|---|---|
| Jawaban langsung untuk pengguna | Synchronous |
| Decoupling, buffering, fan-out | Asynchronous |
| Temporal coupling kuat OK | Synchronous |
| Resilience terhadap outage downstream | Asynchronous |

## Pitfall

**Rantai synchronous** yang panjang (A → B → C → D) menggandakan latency dan probabilitas kegagalan. Lebih baik async atau aggregation jika memungkinkan.

## Mengapa ini penting

Gaya komunikasi membentuk resilience sistem: panggilan synchronous mudah dipahami tetapi menciptakan tight runtime coupling, sementara async messaging mendapatkan decoupling dengan biaya eventual consistency.

Sebagian besar sistem nyata mencampur keduanya — sync untuk user-facing reads, async untuk background workflows.

Kebutuhan	Pilih
Jawaban langsung untuk pengguna	Synchronous
Decoupling, buffering, fan-out	Asynchronous
Temporal coupling kuat OK	Synchronous
Resilience terhadap outage downstream	Asynchronous