Kaj je event-driven arhitektura v mikrostoritvah?

Question

Accepted Answer

V **event-driven arhitekturi** storitve komunicirajo z **proizvajanjem in potrošnjo dogodkov** prek brokarja (Kafka, RabbitMQ, itd.). Storitev napove, da se je kaj zgodilo; zainteresirane storitve se odzovejo — proizvajalec ne ve ali ne čaka nanje.

## Kako deluje

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

## Primer event payload-a

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

## Prednosti

- **Ohlapna vezanost** — dodajte novega potrošnika brez spreminjanja proizvajalca.
- **Odpornost** — broker puferira dogodke med izpadi.
- **Skalabilnost** — potrošniki se skalirajo neodvisno.

## Pasti

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

## Zakaj je to pomembno

Event-driven dizajn je tisto, kar vam omogoča dodajanje zmogljivosti (analitika, preverjanje goljufij, obvestila) z enostavnim naročanjem, brez kakršnih koli sprememb obstoječih proizvajalcev.

Ta razširljivost in odpornost pridejo na račun eventualne konsistentnosti in težjega odpravljanja napak — osrednja kompromis, ki ga sprejmete, ko greste na event-driven.