Что делать, если HTTP‑запрос прошёл, а транзакция в БД откатилась?

В сфере искусственного интеллекта произошло заметное событие. ZheleznyChel 1 час назад Что делать, если HTTP‑запрос прошёл, а транзакция в БД откатилась? 3K Блог компании Timeweb Cloud Распределённые системы * Параллельное программирование * Scala * PostgreSQL * Туториал Перевод Автор оригинала: Haruhiko Nishi ❯ ВведениеСуть проблемы предельно проста: если внешний сетевой запрос завершится успешно, а фиксация изменений в БД сорвется, ваша система зависнет в несогласованном состоянии, которое невозможно откатить. В этой статье мы подробно, шаг за шагом, разберем реально работающую реализацию связки паттернов Transactional Outbox (исходящие транзакции) + Result Table (таблица результатов) + Saga Compensation (компенсирующие транзакции) на языке Scala с использованием Play Framework, Slick и Pekko.

Если ваше приложение одновременно сохраняет данные в базу и отправляет запросы к внешним веб-сервисам, у вас гарантированно возникнет проблема несогласованности данных (проблема двойной записи). Паттерны Transactional Outbox и Saga – это классические, описанные во всех учебниках решения. Однако большинство статей на эту тему ограничиваются голой теорией.

Технические детали

Мы создадим полноценное рабочее приложение, которое вы сможете склонировать, запустить у себя и адаптировать под свои задачи. Проект объединяет три паттерна, которые идеально дополняют друг друга. Transactional Outbox (исходящий почтовый ящик) дает железную гарантию того, что каждое событие будет обработано, даже если само приложение внезапно упадет посреди отправки запроса.

Result Table (таблица результатов) фиксирует детали каждого вызова API, ответы сторонних систем и полученные идентификаторы, которые понадобятся, если операцию придется отменить. Saga Compensation (компенсирующие транзакции) – если, к примеру, четвертый шаг цепочки завершится сбоем, этот механизм автоматически и в правильном порядке откатит предыдущие три шага. В нашем примере используются Play Framework, Scala 3, PostgreSQL, Slick и акторы Pekko.

Тем не менее вся архитектура абсолютно не зависит от языка программирования или фреймворка. Вы можете заменить эти библиотеки на любые аналоги – сами концепции останутся неизменными. Весь материал статьи построен на базе готового проекта.

Настоятельно рекомендую склонировать репозиторий и держать код перед глазами по ходу чтения. Каждый фрагмент кода мы берем напрямую из репозитория:git clone cd never-call-apis-inside-database-transactionsЧтобы запустить его локально:docker-compose up -d postgres sbt run # Открыть проект встроен интерактивный симулятор внешних служб (склад, биллинг, доставка, проверка на мошенничество) с настраиваемой вероятностью сбоев, удобный веб-интерфейс для оформления заказов и провоцирования ошибок, а также подробный журнал аудита для каждого вызова API. О том, как запустить конкретные сценарии, мы поговорим в разделе «Время экспериментов» в конце статьи.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.