Event Sourcing: практичний посібник із впровадження з кодом

Уявіть: інтернет-магазин із 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 — якщо він змінився, запис відхиляється, гарантуючи цілісність.

Часова складність операцій:

Проекції та еволюція схем

Проекції (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:

План впровадження та терміни

1. Аналіз домену та виділення агрегатів (1–2 тижні).
2. Визначення типів подій та їх схем (3–5 днів).
3. Реалізація Event Store (PostgreSQL або готове рішення) — 2–3 дні.
4. Написання агрегатів з бізнес-логікою (3–5 днів на агрегат).
5. Побудова проекцій для read models (5–7 днів).
6. Налаштування знімків для продуктивності (1–2 дні).
7. Інтеграція з брокером повідомлень (Kafka, RabbitMQ) — 3–5 днів.
8. Тестування та моніторинг (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 з урахуванням ваших вимог.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.