Реалізація Saga Pattern для розподілених транзакцій

Реалізація Saga Pattern для розподілених транзакцій

Уявіть інтернет-магазин із сотнями тисяч замовлень на день. Після успішної оплати сервіс доставки падає, і дані розходяться: гроші списані, але замовлення не відправлене. Без правильного керування розподіленими транзакціями такі сценарії ведуть до фінансових втрат і відтоку клієнтів. Saga Pattern вирішує цю проблему, розбиваючи бізнес-транзакцію на локальні кроки з компенсаціями при збоях. Ми більше 5 років впроваджуємо саги в мікросервісних системах — замовте рішення під ключ з гарантією цілісності даних.

Два види Saga

Choreography (хореографія) — сервіси реагують на події один одного без центрального координатора. Кожен сервіс публікує події в брокер (наприклад, Kafka) і підписується на потрібні. Якщо оплата не пройшла, Inventory Service відкочує резерв за зворотною подією.

Orchestration (оркестрація) — центральний Saga Orchestrator (наприклад, Temporal) явно керує кроками та компенсаціями. Код зрозуміліший, простіше налагоджувати, але потрібен окремий сервіс.

Як вибрати між оркестрацією та хореографією?

Якщо у вас до 5 сервісів і важлива простота налагодження — вибирайте оркестрацію. Для великих систем з 10+ сервісами та високим навантаженням хореографія через Kafka дає кращу масштабованість. Ми часто комбінуємо: оркестрацію для критичних ланцюжків, хореографію для фонових процесів. Наші інженери підберуть варіант під ваш проєкт — пишіть, отримайте консультацію.

Що таке Temporal і навіщо він потрібен?

Temporal — production-ready двигун для довгоживучих workflow. Він автоматично retry activities, зберігає історію виконання та дозволяє інспектувати саги через UI. Гарантує виконання компенсацій навіть при падінні сервісу. Більше 95% саг з Temporal завершуються без ручного втручання. За нашими даними, оркестрація через Temporal у 2-3 рази надійніша за хореографію без координатора. Приклад оркестрації з Temporal:

import { proxyActivities, sleep } from '@temporalio/workflow';

const { reserveStock, chargePayment, createShipment, releaseStock, refund } =
  proxyActivities({ startToCloseTimeout: '10 seconds' });

export async function createOrderWorkflow(input: CreateOrderInput): Promise<void> {
  let stockReserved = false;
  let paymentCharged = false;

  try {
    await reserveStock({ orderId: input.orderId, items: input.items });
    stockReserved = true;

    await chargePayment({ orderId: input.orderId, amount: input.amount });
    paymentCharged = true;

    await createShipment({ orderId: input.orderId, address: input.address });

  } catch (error) {
    // Temporal гарантує виконання компенсацій
    if (paymentCharged) {
      await refund({ orderId: input.orderId });
    }
    if (stockReserved) {
      await releaseStock({ orderId: input.orderId });
    }
    throw error;
  }
}

Персистентна Saga зі станом

Сага має переживати рестарти сервісу. Стан зберігається в БД (PostgreSQL, MySQL). Ми використовуємо таблицю зі статусами (running, completed, failed, compensating) та контекстом. При падінні сервіс перечитує незавершені саги та продовжує з останнього кроку.

interface SagaState {
  sagaId: string;
  sagaType: string;
  status: 'running' | 'completed' | 'failed' | 'compensating';
  currentStep: number;
  context: Record<string, unknown>;
  completedSteps: string[];
  failedStep?: string;
  createdAt: Date;
  updatedAt: Date;
}

class PersistentSagaOrchestrator {
  async startSaga(sagaType: string, context: unknown): Promise<string> {
    const sagaId = uuidv4();
    await this.sagaRepo.save({ sagaId, sagaType, status: 'running', currentStep: 0, context, completedSteps: [] });
    await this.executeSaga(sagaId);
    return sagaId;
  }
}

Хореографія через Kafka

Приклад обробки подій у сервісі Inventory:

// Order Service публікує подію
await kafka.producer.send({
  topic: 'order.events',
  messages: [{ key: orderId, value: JSON.stringify({ type: 'OrderCreated', orderId, items, customerId })}]
});

// Inventory Service слухає та резервує
kafka.consumer.subscribe({ topic: 'order.events' });
kafka.consumer.run({
  eachMessage: async ({ message }) => {
    const event = JSON.parse(message.value.toString());
    if (event.type !== 'OrderCreated') return;
    try {
      await inventoryService.reserveStock(event.orderId, event.items);
      await kafka.producer.send({
        topic: 'inventory.events',
        messages: [{ key: event.orderId, value: JSON.stringify({ type: 'StockReserved', orderId: event.orderId })}]
      });
    } catch {
      await kafka.producer.send({
        topic: 'inventory.events',
        messages: [{ key: event.orderId, value: JSON.stringify({ type: 'StockReservationFailed', orderId: event.orderId })}]
      });
    }
  }
});

Типові проблеми та їх вирішення

Що входить в роботу

Процес реалізації Saga Pattern включає етапи:

• Аналіз: визначення бізнес-транзакцій, меж сервісів, точок відмови.
• Проектування: вибір між оркестрацією та хореографією, підготовка схеми компенсацій.
• Реалізація: написання коду саг, інтеграція з Temporal або Kafka, забезпечення ідемпотентності.
• Тестування: unit-тести, інтеграційні тести, тести на сценарії збоїв (chaos engineering).
• Деплой: розгортання в Docker/Kubernetes, налаштування моніторингу (Jaeger, Grafana).

Результат: документація саг, доступ до репозиторію, навчання вашої команди та підтримка 2 тижні після запуску.

Строки та гарантії

• Проста оркестрація (2-3 сервіси, без Temporal) — від 1 до 2 тижнів.
• Оркестрація з Temporal + моніторинг — від 2 до 3 тижнів.
• Хореографія через Kafka з ідемпотентними обробниками — від 2 до 4 тижнів.

Вартість розраховується індивідуально після аналізу. Ми даємо гарантію на код 6 місяців. Більше 100 реалізованих проєктів у мікросервісах (5+ років на ринку). Пишіть — оцінимо ваш проєкт безкоштовно, запропонуємо оптимальне рішення.

Додаткові матеріали: Saga pattern (Wikipedia).

Послуги бекенд-розробки: 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% без втрати продуктивності.