Durable workflows — простая идея для надёжных программ. Ты регулярно сохраняешь контрольные точки прогресса в базу данных. Если программа упала — загружаешься с последней точки. Как сохранение в видеоигре.
Обычно это делают через внешнюю оркестрацию — так работают Temporal, Airflow и AWS Step Functions. У тебя есть центральный оркестратор, который создаёт запись о workflow в хранилище, отправляет задачу воркеру, ждёт результат, сохраняет чекпоинт и запускает следующий шаг. Если воркер упал — оркестратор переотправляет задачу другому воркеру с последнего чекпоинта.
Автор статьи утверждает: внешняя оркестрация фундаментально переусложнена. Ведь core idea — просто чекпоинты в БД. Зачем тогда отдельный сервер-оркестратор? Проще и эффективнее использовать саму базу данных как оркестратор. В статье разбирают конкретный вариант — Postgres, потому что он популярен, масштабируем и имеет богатую экосистему.
В такой системе серверы приложений общаются с Postgres напрямую, без центрального оркестратора. Клиент создаёт запись в таблице workflows, серверы опрашивают таблицу, забирают задачи и выполняют шаги. Каждый шаг — чекпоинт в Postgres. Если сервер упал — другой сервер подхватывает его workflows с последнего чекпоинта. Координация через блокировки (locking clauses), чтобы один workflow выполнял ровно один воркер. Если два воркера попытаются выполнить один и тот же workflow — ограничения целостности БД помогут обнаружить дублирование и отступить.
Замена оркестратора на Postgres решает проблемы масштабирования, доступности, наблюдаемости и безопасности стандартными средствами Postgres. Воркеры взаимозаменяемы, система доступна, пока доступна БД. Один Postgres выдерживает десятки тысяч workflow в секунду (вертикальное масштабирование), а дальше — шардирование или распределённые решения вроде CockroachDB. Для доступности — стриминговая репликация с автоматическим failover и managed-решения с multi-AZ и SLA.
Наблюдаемость встроена — все чекпоинты лежат в Postgres-таблицах, и любой мониторинг делается обычным SQL. Автор показывает пример запроса для поиска всех workflow с ошибками за последний месяц. Реляционная модель позволяет сложные аналитические фильтры, в отличие от key-value хранилищ, которые используют внешние оркестраторы.
Надёжность и безопасность — в схеме с внешним оркестратором и его хранилище — две точки отказа, и они имеют доступ к чувствительным данным. В схеме с Postgres единственная точка отказа — сама БД, все данные хранятся только в ней и никуда не передаются. Если приложение уже использует Postgres, добавление durable execution не создаёт новых точек отказа и новой поверхности атаки. Базы данных — критическая инфраструктура, разумнее использовать их для оркестрации, чем заводить новую критическую инфраструктуру.
Этот подход развивает компания DBOS — они делают durable execution на Postgres максимально простым и производительным.