Что хотят услышать интервьюеры:

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

Определение:

Согласованность между двумя раздельными базами данных — это способ гарантировать, что изменения в обеих системах либо будут применены в согласованном состоянии, либо система сможет корректно восстановиться после сбоя. В обычной локальной транзакции СУБД сама контролирует атомарность, но между двумя независимыми базами такой механизм уже не является “из коробки” общим. Поэтому обычно используют либо распределённые транзакции, либо более практичный подход через саги и компенсации.

Пример использования:

Например, в Node.js сервис создаёт заказ в одной базе и резервирует товар в другой. Если заказ уже записан, а резервирование не удалось, нужно либо отменить заказ, либо пометить его как требующий компенсации. На практике часто делали так: сначала фиксировали событие/состояние в основной базе, затем через очередь или отдельный воркер выполняли вторую операцию и при ошибке запускали обратное действие.

// Упрощённый пример подхода с компенсацией
async function createOrderAndReserveStock(orderRepo, stockRepo, txManager) {
  const order = await txManager.transaction(async (tx) => {
    const createdOrder = await orderRepo.create(
      { status: 'PENDING' },
      { transaction: tx }
    );

    try {
      await stockRepo.reserve(
        { orderId: createdOrder.id, items: createdOrder.items },
        { transaction: tx }
      );

      await orderRepo.updateStatus(createdOrder.id, 'CONFIRMED', { transaction: tx });
      return createdOrder;
    } catch (error) {
      await orderRepo.updateStatus(createdOrder.id, 'CANCELLED', { transaction: tx });
      throw error;
    }
  });

  return order;
}

Пояснение кода:

Код показывает локальную транзакцию в рамках одной базы и логику компенсации на уровне бизнес-процесса. Сначала создаётся заказ со статусом PENDING, чтобы зафиксировать намерение выполнить операцию. Затем выполняется резервирование товара; если оно успешно, заказ переводится в CONFIRMED. Если резервирование падает, заказ отменяется через статус CANCELLED, чтобы система не оставалась в частично завершённом состоянии. В реальной схеме для двух разных баз часто выносили вторую операцию в отдельный шаг через очередь сообщений, а не пытались держать обе базы в одной синхронной транзакции.

Ключевые моменты:

Между двумя независимыми базами нет “магической” общей транзакции по умолчанию.
Для строгой атомарности используют распределённые транзакции, но они сложнее и дороже в эксплуатации.
На практике чаще применяют саги, компенсационные операции и событийную согласованность.
Важны идемпотентность операций и безопасные повторные попытки.
Нужны статусы состояния, чтобы бизнес-процесс можно было восстановить после сбоя.
При собеседовании полезно отдельно упомянуть обработку частичных ошибок и мониторинг “зависших” транзакционных сценариев.

Каким образом вы реализовали согласованность данных между двумя раздельными базами данных при выполнении транзакций?