Çfarë është arkitektura event-driven në microservices?

Question

Accepted Answer

Në një **arkitekturë event-driven**, shërbimet komunikojnë duke **prodhuar dhe konsumuar ngjarje** përmes një broker-i (Kafka, RabbitMQ, etj.). Një shërbim njofton se ndodhi diçka; shërbimet e interesuara reagojnë — prodhuesi nuk e di ose nuk pret ato.

## Si funksionon

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

## Shembull i event payload

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

## Përfitimet

- **Lidhje e lirshme** — shtoni një konsumator të ri pa prekur prodhusin.
- **Reziliencë** — broker-i ruaj ngjarjet gjatë ndërprerjeve.
- **Skalabilitet** — konsumatorët shkallëzohen në mënyrë të pavarur.

## Rreziqet

```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
```

## Pse është e rëndësishme

Dizajni event-driven është ajo që ju lejon të shtoni aftësi (analitika, kontrolli i mashtrimit, njoftimet) thjesht duke u abonuar, pa asnjë ndryshim në produserët ekzistues.

Kjo zgjerueshëmëri dhe reziliencë vijnë me çmimin e konsistencës përfundimtare dhe debugimit më të vështirë — kompromisi qendror që pranoni kur shkoni event-driven.