Apakah itu event-driven architecture dalam microservices?

Question

Accepted Answer

Dalam sebuah **event-driven architecture**, perkhidmatan berkomunikasi dengan **menghasilkan dan menggunakan event** melalui broker (Kafka, RabbitMQ, dan lain-lain). Sesuatu perkhidmatan mengumumkan bahawa sesuatu telah berlaku; perkhidmatan yang berminat bertindak balas — penghasil tidak tahu atau menunggu mereka.

## Bagaimana ia berfungsi

```text
Order Service ─publish→ [ Event Broker: "order.placed" ]
                              │
            ┌─────────────────┼──────────────────┐
            ▼                 ▼                  ▼
      Inventory         Notification          Analytics
      (reserve stock)   (send email)          (record metric)
```

## Contoh payload event

```json
{
  "eventType": "order.placed",
  "eventId": "e-9f2c",          // unique → consumers dedupe
  "occurredAt": "2026-06-18T10:00:00Z",
  "data": { "orderId": "42", "total": 99.5 }
}
```

## Faedah

- **Loose coupling** — tambah consumer baharu tanpa menyentuh penghasil.
- **Daya tahan** — broker menampan event semasa gangguan.
- **Kebolehskalaan** — consumer diskalakan secara bebas.

## Perangkap

```text
⚠️ Eventual consistency — readers may briefly see stale data
⚠️ Duplicate delivery — make consumers idempotent (use eventId)
⚠️ Ordering — only guaranteed within a partition/queue
⚠️ Hard to trace a flow across many consumers
```

## Mengapa ia penting

Reka bentuk event-driven adalah apa yang membolehkan anda menambah keupayaan (analitik, semakan penipuan, pemberitahuan) hanya dengan melanggan, tanpa sebarang perubahan pada penghasil sedia ada.

Kebolehlanjutan dan daya tahan itu datang dengan harga eventual consistency dan penyahpepijatan yang lebih sukar — pertukaran utama yang anda terima apabila beralih kepada event-driven.