Mikä on tapahtumaohjattu arkkitehtuuri mikropalveluissa?

Question

Accepted Answer

**Tapahtumaohjautussa arkkitehtuurissa** palvelut kommunikoivat **tuottamalla ja kuluttamalla tapahtumia** välittäjän (Kafka, RabbitMQ jne.) kautta. Palvelu ilmoittaa, että jotain tapahtui; kiinnostuneet palvelut reagoivat — tuottaja ei tiedä niistä tai odota niitä.

## Kuinka se toimii

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

## Esimerkki tapahtuman hyötykuormasta

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

## Hyödyt

- **Löyhä kytkentä** — lisää uusi kuluttaja koskematta tuottajaan.
- **Resilienssi** — välittäjä puskuroi tapahtumia katkoksien aikana.
- **Skaalautuvuus** — kuluttajat skaalautuvat itsenäisesti.

## Sudenkuopat

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

## Miksi se on tärkeää

Tapahtumaohjattu suunnittelu on se, joka mahdollistaa kyvykkyyksien (analytiikka, petostentarkistus, ilmoitukset) lisäämisen yksinkertaisesti tilaamalla ilman muutoksia olemassa oleviin tuottajiin.

Tämä laajennettavuus ja resilienssi tulevat lopulta johdonmukaisen tiedon ja vaikeamman debuggaamisen hintaan — keskeinen kompromissi, jonka hyväksyt siirryttäessä tapahtumaohjautuun arkkitehtuuriin.