На QCon San Francisco команда DBOS предложила спорную на первый взгляд идею: не выносить orchestration в отдельный сервис, а собирать durable execution прямо в уже существующей базе данных. Для разработчиков, которые строят AI-пайплайны, обработку документов и долгие бизнес-процессы, это звучит не как академический трюк, а как попытка выкинуть из схемы лишний класс отказов.
В 49-минутной презентации, как пишет InfoQ, CEO DBOS и бывший founding reliability engineer Netflix Джереми Эдберг вместе с соосновательницей компании Цянь Ли разобрали, почему внешние оркестраторы часто делают систему не надежнее, а хрупче. Их тезис простой: если приложение и так хранит состояние в СУБД, логично там же держать состояние workflow, очереди, retries и ключи идемпотентности, а не гонять данные через еще один распределенный слой.
Отправной пример у докладчиков вполне прикладной: нужно обработать миллионы документов, прогнать их через AI и потом дать пользователю возможность задавать по ним вопросы. Типичная архитектура для такой задачи давно знакома любому backend-инженеру: сервис скачивает документ, кладет задачу в очередь, другой сервис обрабатывает файл, следующий отправляет результат в AI-компонент или индекс. В роли клея обычно выступают RabbitMQ, Kafka или похожий координатор. Проблема не в том, что эта схема не работает. Проблема в том, что ломается в ней почти все: загрузка из интернета, сами AI-вызовы, промежуточные воркеры, повторные запросы пользователей через дни или недели, а еще логика повторов и дедупликации, которую кто-то должен поддерживать.
На этом месте DBOS атакует любимый паттерн индустрии: «добавим еще один надежный сервис, чтобы стало надежнее». По версии Эдберга, внешний durable orchestrator создает ровно то, от чего должен спасать. Он добавляет новые точки отказа, лишние сетевые переходы, накладные расходы на инфраструктуру и необходимость переписывать приложение под модель worker/producer. Вместо того чтобы уменьшать attack surface, команда его расширяет: теперь отказать может не только бизнес-логика, но и сам координатор, его API, его хранилище состояния и все интеграции вокруг. Для команды, которая уже устала от набора «очередь, воркеры, ретраи, мониторинг к ретраям, мониторинг к мониторингу», аргумент неприятно узнаваемый.
Техническая часть презентации интереснее слогана. DBOS Transact, который докладчики называют open-source библиотекой, опирается не на экзотические механизмы, а на стандартные таблицы базы данных, уникальные первичные ключи и очередь на базе SKIP LOCKED. Это важно: речь не о специальной workflow-СУБД и не о новом брокере сообщений, а об использовании уже привычных примитивов SQL для планирования и выполнения шагов. Уникальные ключи отвечают за защиту от дублей и помогают двигаться к exactly-once semantics там, где это нужно бизнесу, будь то платеж, обработка документа или дорогой AI-вызов. Таблицы становятся журналом состояния, а SKIP LOCKED позволяет нескольким воркерам безопасно разбирать задания без тяжелой конкуренции за одну и ту же запись.
Здесь же всплывает еще один болезненный момент современных AI-систем: они плохо укладываются в старые операционные шаблоны. Последние десятилетия инфраструктура затачивалась либо под очень короткие запросы веб-приложений, где ответ должен прийти примерно за секунду или быстрее, либо под batch-задачи, когда пользователь вообще не ждет результата у экрана. AI работает в промежутке: ответ часто занимает секунды, пользователь ждет, а потом может вернуться к тому же процессу спустя часы, дни или недели. Именно для такой модели durable execution становится не красивым архитектурным словом, а способом не переплатить за повторные инференсы, не потерять состояние и не объяснять клиенту, почему его задача «почти завершилась», но все равно исчезла.
Отдельный аргумент DBOS касается наблюдаемости. Очереди и внешние оркестраторы часто превращают диагностику в археологию: нужно отдельно выяснять, что лежит в очереди, что зависло, что ретраилось, где сломался шаг и сохранился ли контекст. Докладчики указывают, что при хранении workflow в базе видимость получается почти бесплатно: состояние шагов, результаты, статусы повторов и служебные метаданные уже лежат в SQL-таблицах, по которым можно делать обычные запросы. Для инженера эксплуатации это звучит куда приятнее, чем очередной поход в отдельную консоль координатора с неполной картиной мира.
У идеи, конечно, есть границы применимости, и их презентация не отменяет. Такой подход требует дисциплины в моделировании транзакций, аккуратной работы с блокировками и понимания того, как конкретная СУБД ведет себя под высокой конкуренцией. Кроме того, тезис «используйте ту же базу, что и для данных приложения» хорош ровно до того момента, пока эта база не становится главным узким местом всей платформы. Но в этом и ценность выступления: DBOS не обещает магию, а напоминает, что часть задач индустрия, возможно, слишком быстро отдала внешним оркестраторам просто потому, что так было модно и удобно продавать.
Для русскоязычных команд здесь есть вполне практический вывод. Если ваш AI-процесс уже живет вокруг PostgreSQL или другой транзакционной СУБД, стоит хотя бы пересчитать цену привычной схемы с отдельным оркестратором: сколько в ней сетевых прыжков, сколько дублирования состояния, сколько кода на retries и сколько часов уходит на разбор инцидентов. На фоне взрывного роста AI-функций durable execution перестает быть темой для platform engineering-команд из больших компаний. Это уже повседневный вопрос для любого продукта, где ошибка в workflow означает не просто баг, а лишние деньги, потерянный контекст и раздраженного пользователя. И если отрасль всерьез начнет возвращать orchestration обратно в базу данных, спор пойдет уже не о красоте архитектуры, а о том, сколько внешних систем нам на самом деле были нужны.