რა არის event-driven architecture მიკროსერვისებში?

Question

Accepted Answer

**Event-driven architecture**-ში სერვისები ერთმანეთს კომუნიკაციას ახორციელებენ **events-ის წარმოშობით და მოხმარებით** broker-ის მাშინ (Kafka, RabbitMQ და სხვ.). სერვისი აცხადებს, რომ რაიმე მოხდა; დაინტერესებული სერვისები რეაგირებენ — producer არ იცის მათ შესახებ და არ ელის მათ.

## როგორ მუშაობს

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

## Event payload-ის მაგალითი

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

## სარგებელი

- **Loose coupling** — ახალი consumer-ის დამატება producer-ის შეხების გარეშე.
- **Resilience** — broker აბაფერს events-ებს გაწყვეტის დროს.
- **Scalability** — consumers დამოუკიდებლად იზრდება.

## პრობლემები

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

## რატომ არის მნიშვნელოვანი

Event-driven დიზაინი ის არის, რაც საშუალებას აძლევს თქვენ დაამატოთ შესაძლებლობები (analytics, fraud checks, notifications) უბრალოდ subscription-ის გზით, არსებული producers-ის ნულოვანი ცვლილებებით.

ეს გაფართოვებულობა და resilience მოდის eventual consistency-ის ფასად და უფრო რთული debugging-ის — ცენტრალური trade-off, რომელიც თქვენ მიიღებთ event-driven-ზე გადასვლისას.