Как решаются проблемы с консистентностью данных в микросервисах?

Проблема консистентности в микросервисах

В монолите транзакция охватывает несколько таблиц в одной базе данных, обеспечивая атомарность. В микросервисах каждый сервис владеет своей БД, поэтому классические ACID-транзакции невозможны. Если операция затрагивает несколько сервисов, нужно гарантировать, что либо все изменения применятся, либо система придёт в согласованное состояние.

Основные подходы

• Saga pattern — разбиение операции на локальные транзакции, каждая из которых выполняется в своём сервисе. При сбое запускаются компенсирующие действия (например, отмена заказа).
• Outbox pattern — сервис записывает данные и событие в одну локальную транзакцию, затем отдельный процесс публикует событие в брокер. Это гарантирует, что событие не потеряется.
• Eventual consistency — система допускает временное расхождение, но со временем приходит к согласованному состоянию через асинхронные обновления.
• Идемпотентность — повторное выполнение операции даёт тот же результат, что защищает от дублирования при ретраях.

Пример саги на JavaScript

async function createOrder(order) {
  try {
    await orderService.create(order);
    await paymentService.charge(order);
    await inventoryService.reserve(order);
  } catch (error) {
    await paymentService.refund(order);
    await inventoryService.release(order);
    throw error;
  }
}

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

Для большинства бизнес-процессов достаточно саги и eventual consistency. Outbox полезен, когда нужно надёжно доставлять события между сервисами. Двухфазный коммит (2PC) применяют редко из-за блокировок и низкой доступности, только если требуется строгая атомарность (например, финансовые операции).

Вывод: В микросервисах консистентность достигается не через глобальные транзакции, а через композицию локальных операций, компенсации и асинхронные события. Выбор паттерна зависит от требований к согласованности и допустимой задержке.