Что такое архитектура, управляемая событиями, в микросервисах?

Question

Accepted Answer

В **архитектуре, управляемой событиями**, сервисы взаимодействуют, **производя и потребляя события** через брокер (Kafka, RabbitMQ и т. д.). Сервис объявляет, что что-то произошло; заинтересованные сервисы реагируют — производитель их не знает и не ждет.

## Как это работает

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

## Пример полезной нагрузки события

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

## Преимущества

- **Слабая связанность** — добавьте нового потребителя без изменения производителя.
- **Устойчивость** — брокер буферизирует события во время сбоев.
- **Масштабируемость** — потребители масштабируются независимо.

## Подводные камни

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

## Почему это важно

Архитектура, управляемая событиями, позволяет вам добавлять возможности (аналитика, проверка мошенничества, уведомления) просто подписываясь, без каких-либо изменений в существующих производителях.

Эта расширяемость и устойчивость достигаются ценой итоговой согласованности и более сложной отладки — центральный компромисс, который вы принимаете, переходя на управляемую событиями архитектуру.