Потоки данных и событийная архитектура

Принцип

Мы используем event-driven архитектуру для асинхронного взаимодействия между сервисами. Это обеспечивает:

• Слабую связанность между сервисами
• Масштабируемость
• Устойчивость к сбоям отдельных компонентов

Паттерны обмена данными

Request-Response (синхронный)

Client → Service A → Service B → Response → Client

Когда использовать: нужен немедленный ответ (чтение данных, валидация).

Event-Driven (асинхронный)

Service A → Event Bus → Service B
                      → Service C
                      → Service D

Когда использовать: операция не требует немедленного ответа, нужна расширяемость.

CQRS (Command Query Responsibility Segregation)

Command → Write Model → Event → Read Model → Query

Когда использовать: разная нагрузка на чтение и запись, сложные проекции данных.

Схема событий

Именование событий

<domain>.<entity>.<action>

payments.transaction.created
users.profile.updated
orders.order.cancelled

Формат события

{
  "event_id": "uuid",
  "event_type": "payments.transaction.created",
  "timestamp": "2025-01-01T00:00:00Z",
  "version": 1,
  "source": "payments-service",
  "data": {
    "transaction_id": "uuid",
    "amount": 100.00,
    "currency": "RUB"
  },
  "metadata": {
    "correlation_id": "uuid",
    "user_id": "uuid"
  }
}

Гарантии доставки

Гарантия	Описание	Когда
At-most-once	Может потеряться	Некритичные нотификации
At-least-once	Может дублироваться	Большинство случаев
Exactly-once	Ровно один раз	Финансовые операции

WARNING

При at-least-once консюмеры должны быть идемпотентными.

Dead Letter Queue

Сообщения, которые не удалось обработать после N попыток, попадают в DLQ:

1. Максимум 3 retry с exponential backoff
2. После этого — в DLQ
3. DLQ мониторится алертами
4. Ручная обработка или replay