Event-driven архитектура на собеседовании системного аналитика

Зачем спрашивают на собесе SA

EDA — современная архитектурная парадигма. На собесе SA: «отличие event и command», «зачем event sourcing», «CQRS».

Event vs Command

Command. Императивное «сделай X». Имя в инфинитиве: CreateOrder, ChargeCard. Ожидает конкретного receiver.

Event. Декларативное «X произошло». Имя в past tense: OrderCreated, CardCharged. Может быть прочитано many subscribers.

Command: CreateOrder{customer_id, items} → Order Service
Event: OrderCreated{order_id, customer_id, total} → Kafka → multiple consumers

Event-driven architecture

Сервисы общаются через events, а не sync RPC.

Order Service → publishes "OrderCreated" → Kafka
                                         ├→ Inventory Service (reserves)
                                         ├→ Notification Service (email)
                                         └→ Analytics Service (logs)

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

• Loose coupling — Order Service не знает про Inventory.
• Resilience — если Notification down, Order continues.
• Scalability — каждый consumer scales independently.
• Audit trail — все events в логах.

Минусы:

• Eventual consistency — не immediate.
• Сложнее отладка (распределённый flow).
• Schema evolution challenge.

Event sourcing

Storage. Не «текущее состояние», а полная история events.

Текущее состояние = replay events.

Events:
1. AccountOpened{id=42}
2. Deposited{id=42, amount=100}
3. Deposited{id=42, amount=50}
4. Withdrawn{id=42, amount=30}

Current state = replay → balance = 120

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

• Полная audit trail.
• Time travel — состояние в любой момент.
• Rebuild views.

Минусы:

• Сложнее.
• Большой storage (все events).
• Schema evolution events.

CQRS

Command Query Responsibility Segregation. Разделение write модели и read модели.

Write side:                Read side:
Commands → Aggregate       Queries → Read DB
       ↓                          ↑
       Events → Event Store      ↑
                ↓                ↑
                Projection ─────┘

Read DB — оптимизирована под запросы (denormalized, multiple views per use case).

Write side — оптимизирован под consistency.

Пара с event sourcing — стандарт для финансовых / regulatory систем.

Когда применять

Event-driven (без full ES/CQRS):

• Микросервисы с loose coupling.
• High-volume events.
• Asynchronous workflows.

Event sourcing:

• Audit-критичные (банкинг, биллинг).
• Compliance (нужна история).
• Temporal queries.

Full CQRS:

• Сложный бизнес domain.
• Read >> write workload.
• Multiple read views.

Не подходит:

• Простой CRUD.
• Низкая нагрузка.
• Небольшая команда без EDA опыта.

Частые ошибки

Анемичные events. «UserChanged» — недостаточно. Нужно what changed and why.

Event = command. Subscriber не должен полагаться на specific consumer behavior.

ES без infrastructure. Без proper event store / projections — тяжело поддерживать.

Schema breaking без version. Old subscribers падают на new event format.

Event sourcing для всего. Overkill для простых CRUD сущностей.

Не учитывать ordering. Events в Kafka per-partition ordered, не globally. Учитывать в design.

Связанные темы

• Kafka на собесе SA
• Webhook polling SSE для SA
• 2PC vs Saga для SA
• Монолит vs микросервисы для SA
• Подготовка к собесу системного аналитика

FAQ

Event sourcing — единственный путь к audit?

Нет. Можно log changes в audit table рядом с current state. ES — более radical, но даёт больше возможностей.

Это официальная информация?

Нет. Статья основана на работах Greg Young (CQRS), Martin Fowler (event sourcing).

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.