Skip to main content

Як зберігати події в event store?

В event sourcing усі зміни стану зберігаються у спеціальному сховищі - event store, де кожен об'єкт представлений як послідовність подій. Головна ідея: нічого не перезаписується, усе додається у вигляді нових подій.

1. Структура зберігання

Кожна подія - це окремий запис із такими полями:

javascript
{ event_id: UUID, // унікальний ідентифікатор aggregate_id: UUID, // до якого об'єкта (наприклад, замовлення) належить event_type: "OrderCreated", payload: {...}, // дані події timestamp: "2025-11-12T16:00:00Z", version: 3 // порядковий номер для відтворення }

Події сортуються за aggregate_id і version - це і є історія конкретного об'єкта.

2. Де зберігати події

  • Спеціалізовані event store системи: EventStoreDB, Axon Server, Kafka (log-based), Cassandra.
  • Реляційні БД: можна зберігати події в таблиці events, де aggregate_id + version - унікальний ключ.
  • NoSQL: MongoDB або DynamoDB підійдуть для потокових сценаріїв.

3. Принципи зберігання

  1. Тільки додавання (append-only): жодного оновлення чи видалення подій.
  2. Незмінність: кожна подія - факт, її не можна виправляти.
  3. Версіювання: події повинні відтворюватися в тому порядку, в якому сталися.
  4. Проєкції: для швидких запитів створюються окремі таблиці з агрегованими даними («read models»).

4. Читання і відновлення

Щоб отримати поточний стан:

  • вибираються всі події за aggregate_id,
  • відтворюються в пам'яті в хронологічному порядку,
  • застосовується логіка «replay», формуючи фінальний стан.

5. Зберігання в продакшені

  • Події можна архівувати, ділити за типами або часовими діапазонами.
  • Для безпеки додають контрольні суми (щоб перевірити цілісність).

Підсумок:

В event store дані не оновлюються, а дописуються як потік незмінних подій. Це створює надійний журнал історії, з якого можна відновити будь-який стан системи.

Коротка відповідь

Для співбесіди
Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.