Event sourcing deep на собеседовании системного аналитика

Идея

Source of truth = events log, не current state. State derived через replay.

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

State derived: balance = 120.

Event store

Append-only log immutable events.

Implementations:

• EventStoreDB.
• Kafka (с infinite retention).
• Postgres event_store table.
• Apache Pulsar.

Properties:

• Append-only.
• Per-aggregate stream (events для one Order — one stream).
• Optimistic concurrency control via version.

Snapshots

Replay 100k events каждое read — slow.

Snapshot. Periodic state save. Replay from latest snapshot.

Events 1-1000 → snapshot v1.
Events 1001-2000 → snapshot v2.
Read = load snapshot v2 + replay 2001-current.

Trade-off — storage vs replay cost.

Projections

Read models built from events. Materialized for queries.

Order events → projection "OrderSummary" (denormalized table).
              → projection "CustomerHistory".
              → projection "DailyRevenue".

Multiple projections по different query needs.

Replay

При rebuild projection — re-process events from start.

Use cases:

• New projection added — backfill.
• Bug в projection logic — re-derive.
• Schema change — restructure.
• Audit / debugging.

Powerful — но slow на huge event count.

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

Подходит:

• Audit critical (banking, compliance).
• Need temporal queries («state на 2026-04-15»).
• Multiple projections / read views.
• Domain с много state changes.

Overkill:

• Simple CRUD.
• No audit requirements.
• Маленькая команда.

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

• Domain events для SA
• Event-driven архитектура для SA
• CQRS для SA
• DDD для SA
• Подготовка к собесу системного аналитика

FAQ

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

Нет. Статья основана на работах Greg Young, Vaughn Vernon.

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