Уявіть: інтернет-магазин із 10 000 замовлень на день. Клієнт скасовує замовлення, менеджер змінює статус, система втрачає історію. Відновити ланцюжок дій неможливо — в базі лише поточний стан. Без Event Sourcing аудит потребує костилів: логування, тригери, додаткові таблиці. Один наш клієнт із фінтеху витратив два місяці на розслідування інциденту, тому що не було історії. Після впровадження Event Sourcing ми скоротили час аудиту на 80%, що заощадило клієнту понад $50 000 на рік. Наша команда має 5+ років досвіду впровадження Event Sourcing, реалізувала понад 10 проєктів. Event Sourcing — ключовий патерн подієво-орієнтованої архітектури, при якому кожна зміна стану застосунку фіксується як незмінна подія. Поточний стан відновлюється повторним застосуванням усіх подій. Event Sourcing — шаблон проєктування, що зберігає послідовність подій.
Архітектура Event Sourcing: Event Store, Aggregates і Replay
Event Store — основа
Основна таблиця — append-only. Жодного UPDATE і DELETE:
CREATE TABLE event_store ( id BIGSERIAL PRIMARY KEY, event_id UUID UNIQUE NOT NULL, aggregate_id UUID NOT NULL, aggregate_type VARCHAR(100) NOT NULL, event_type VARCHAR(100) NOT NULL, event_version INT NOT NULL DEFAULT 1, payload JSONB NOT NULL, metadata JSONB NOT NULL DEFAULT '{}', occurred_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), sequence_nr BIGINT NOT NULL -- глобальний порядок ); CREATE INDEX idx_es_aggregate ON event_store (aggregate_id, aggregate_type, id); CREATE INDEX idx_es_sequence ON event_store (sequence_nr); Оптимістичне блокування — перевірка sequence_nr перед записом нової події запобігає конфліктам конкурентних записів. Event Sourcing з PostgreSQL у 10 разів дешевший за спеціалізовані рішення, але забезпечує достатню продуктивність для 95% проєктів.
Aggregates: бізнес-логіка на подіях
class OrderAggregate { private state: OrderState = { status: 'new', items: [], total: 0 }; private version = 0; private uncommittedEvents: DomainEvent[] = []; static rehydrate(events: DomainEvent[]): OrderAggregate { const order = new OrderAggregate(); for (const event of events) { order.apply(event); } return order; } placeOrder(items: OrderItem[]) { if (this.state.status !== 'new') throw new Error('Order already placed'); this.raise({ eventType: 'OrderPlaced', payload: { items, placedAt: new Date() } }); } private apply(event: DomainEvent) { switch (event.eventType) { case 'OrderPlaced': this.state.status = 'placed'; this.state.items = event.payload.items; break; case 'PaymentProcessed': this.state.status = 'paid'; this.state.paidAmount = event.payload.amount; break; case 'OrderShipped': this.state.status = 'shipped'; this.state.trackingNumber = event.payload.trackingNumber; break; } this.version++; } } Replay і знімки
При великій кількості подій на агрегат (понад 500) повний replay стає повільним. Знімок — серіалізований стан на момент N-ї події. При завантаженні читається останній знімок + події після нього.
Як знімки покращують продуктивність?
async loadAggregate(aggregateId: string): Promise<OrderAggregate> { const snapshot = await this.snapshotRepo.findLatest(aggregateId); const fromSequence = snapshot?.version ?? 0; const events = await this.eventStore.getEvents( aggregateId, { fromVersion: fromSequence } ); const aggregate = snapshot ? OrderAggregate.fromSnapshot(snapshot) : new OrderAggregate(); return aggregate.rehydrate(events); } Знімки створюються асинхронно кожні 100–500 подій на агрегат. Оптимістичне блокування при записі нової події перевіряє sequence_nr — якщо він змінився, запис відхиляється, гарантуючи цілісність.
Часова складність операцій:
| Операція | Без знімків | Зі знімками |
|---|---|---|
| Завантаження агрегату (N подій) | O(N) | O(нещодавні події) |
| Запис події | O(1) | O(1) |
| Запит за станом | O(N) projection rebuild | O(1) read model |
Проекції та еволюція схем
Проекції (Read Models) для швидкого читання
Event Sourcing диктує розділення Write Model (події) та Read Model (проекції для запитів). Це типова реалізація CQRS. Проекція підписується на потік подій і будує денормалізовану таблицю:
class OrderProjection { async on(event: DomainEvent) { switch (event.eventType) { case 'OrderPlaced': await db.query(` INSERT INTO orders_view (id, status, customer_id, total, created_at) VALUES ($1, 'placed', $2, $3, $4) `, [event.aggregateId, event.payload.customerId, event.payload.total, event.occurredAt]); break; case 'OrderShipped': await db.query(` UPDATE orders_view SET status = 'shipped', tracking_number = $2, shipped_at = $3 WHERE id = $1 `, [event.aggregateId, event.payload.trackingNumber, event.occurredAt]); break; } } } Проекції можна видалити і перезібрати з нуля — історія подій повна.
Schema Evolution: як не зламати історію
Версіонування схем подій — обов'язкова практика. Стратегії:
- Upcasting — при читанні старої події трансформувати її до нової схеми.
- Weak schema — JSON дозволяє додавати поля без поломки.
- Event versioning — зберігати
eventVersion, читати з різними хендлерами.
Інструменти для Event Store
Готові рішення:
- EventStoreDB — спеціалізована СУБД з підписками та проекціями.
- Marten (.NET) — PostgreSQL як Event Store + документна БД.
- Axon Framework (Java) — повний ES/CQRS фреймворк.
Самописний на PostgreSQL достатній для більшості проєктів. LISTEN/NOTIFY для сповіщення проекцій про нові події. Брокер подій (Kafka, RabbitMQ, NATS JetStream) для розподілу між сервісами.
Порівняння реалізації Event Store:
| Рішення | Продуктивність | Готовність | Складність |
|---|---|---|---|
| PostgreSQL самописний | ~10 000 записів/с | Низька (потрібна розробка) | Середня |
| EventStoreDB | ~100 000 записів/с | Висока (коробкове) | Низька |
| Marten | ~5 000 записів/с | Середня (є .NET) | Середня |
План впровадження та терміни
- Аналіз домену та виділення агрегатів (1–2 тижні).
- Визначення типів подій та їх схем (3–5 днів).
- Реалізація Event Store (PostgreSQL або готове рішення) — 2–3 дні.
- Написання агрегатів з бізнес-логікою (3–5 днів на агрегат).
- Побудова проекцій для read models (5–7 днів).
- Налаштування знімків для продуктивності (1–2 дні).
- Інтеграція з брокером повідомлень (Kafka, RabbitMQ) — 3–5 днів.
- Тестування та моніторинг (1–2 тижні).
Терміни: базовий Event Store на PostgreSQL — 2–3 дні. Один агрегат — 3–5 днів. Проекції + підписки + знімки — ще 5–7 днів. Повна система з кількома агрегатами, schema evolution та моніторингом — 3–5 тижнів.
Що входить у роботу
Ми надаємо:
- Документація за подіями та схемами.
- Код агрегатів, проекцій та знімків.
- Налаштування Event Store (PostgreSQL або EventStoreDB).
- Інтеграція з брокером повідомлень.
- Навчання команди роботі з Event Sourcing.
- Підтримка після впровадження (1 місяць).
Чому варто обрати Event Sourcing?
- Повна історія змін для аудиту.
- Можливість відкату до будь-якого стану.
- Розділення write та read моделей (CQRS).
- Простота додавання нових проекцій без міграцій.
Отримайте консультацію — ми проаналізуємо ваш домен і запропонуємо оптимальне рішення. Зв'яжіться з нами для оцінки вашого проєкту. Ми допоможемо впровадити Event Sourcing з урахуванням ваших вимог.