Hacker News Digest

Armin Ronacher разработал библиотеку Absurd — решение для создания надежных рабочих процессов, использующее только Postgres без дополнительных сервисов. В ответ на растущий спрос на устойчивое выполнение (durable execution) в эпоху AI-агентов, он создал минималистичную систему на основе единственного SQL-файла. Библиотека решает проблему сохранения состояния при сбоях, используя возможности Postgres для управления очередями и хранения чекпоинтов. Ключевая особенность — деление задач на шаги, которые автоматически восстанавливаются после перезапуска, избегая дублирования работы.

Для AI-агентов Absurd предлагает элегантный подход с автоматической нумерацией повторяющихся шагов. Пример кода демонстрирует задачу с единственным шагом "iteration", которая при повторении превращается в "iteration#2", "iteration#3" и т.д., сохраняя только новые сообщения. Система поддерживает приостановку задач, ожидание событий и автоматическую загрузку состояния из чекпоинтов. Запуск осуществляется через простую функцию absurd.spawn(), а обработка ошибок включает механизм повторов с ограничением попыток.

• Обсуждение в основном вращается вокруг двух тем: длительное выполнение задач (durable execution) и инструментов для этого, таких как Absurd SQL и Temporal, а также их сравнение с другими решениями, включая DBOS и Cadence.
• Участники обсуждают, что такие инструменты как Absurd SQL и Temporal предоставляют простоту и надежность, но могут быть сложны в использовании и требуют дополнительной настройки.
• Также обсуждается, что такие инструменты как Absurd SQL и Temporal могут быть полезны для обеспечения надежности и простоты в работе с агентами и их непредсказуемым поведением.
• Участники также обсуждают, что такие инструменты как Absurd SQL и Temporal могут быть полезны для обеспечения надежности и простоты в работе с агентами и их непредсказуемым поведением.
• В конце обсуждение сосредотачивается на том, что такие инструменты как Absurd SQL и Temporal могут быть полезны для обеспечения надежности и простоты в работе с агентами и их непредсказуемым поведением.

DBOS Transact для Go — это фреймворк для оркестрации устойчивых рабочих процессов, использующий PostgreSQL как единый источник истины. Он позволяет писать транзакционные приложения на Golang, где бизнес-логика выполняется атомарно и изолированно, а состояние автоматически сохраняется в базе данных. Это устраняет необходимость в отдельных системах управления состоянием или очередях, упрощая архитектуру и повышая надёжность.

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

• Сравнение с Temporal и другими системами оркестрации рабочих процессов, обсуждение подхода DBOS как библиотеки против внешнего сервиса, вопросы об идемпотентности и гарантиях обработки событий.
• Вопросы о технических особенностях DBOS: масштабируемость в кластере, версионирование рабочих процессов, приоритизация заданий, безопасность и варианты развертывания без исходящего сетевого доступа.
• Обсуждение архитектурных решений и альтернатив, таких как pgglow, и их интеграция с Postgres и клиентами на разных языках.
• Связь проекта с академическими исследованиями (DBOS OS) и его дальнейшее развитие, включая планы по поддержке новых языков и функциональности.
• Реакция сообщества: от положительных отзывов о простоте модели до скептических вопросов о гарантиях и практическом применении, а также упоминание частоты постов о проекте.

Как я решил проблему распределённой очереди через 15 лет

В Reddit всё — голоса, комментарии, посты — сначала попадало в RabbitMQ, потом в базу.
Очередь давала горизонтальное масштабирование, шейпинг и cron, но падала: задача могла исчезнуть после взятия из очереди или при краше брокера. Нужны были долговечные очереди, сохраняющие состояние в Postgres.

Сегодня это реализуется через долговечные workflow: каждый шаг чек-поинтится в БД, задачи запускаются параллельно, при падении продолжаются с последнего сохранённого места.

• Пост вызвал спор: одни хвалят вводный уровень, другие ждут разбора «распределённой» сложности и конкретного решения.
• Критика: заголовок обещает «как я решил», но статья не формулирует проблему и не показывает шаги решения.
• Автор подменяет «очереди» «устойчивыми воркфлоу»; читатели считают, что это разные вещи.
• RabbitMQ 15-летней давности обвинили в отсутствии надёжного бэкапа состояния; Kafka, наоборот, приводят как пример «и быстро, и надёжно», но её обвиняют в перекладывании сложности на потребителя.
• Главная идея DBOS: устойчивость без внешнего координатора и без переписывания кода под async-рантайм.

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

• Масштабируемые очереди
  Классическая таблица-очередь страдает от конкуренции: все воркеры пытаются взять одни и те же задачи. Postgres решает это через FOR UPDATE SKIP LOCKED: строки блокируются и пропускаются, если уже захвачены. Воркеры без конфликтов берут следующие N записей, позволяя обрабатывать десятки тысяч задач в секунду.

• Наблюдаемость
  Каждый шаг сохраняется, поэтому можно строить дашборды и фильтры. SQL позволяет писать сложные запросы напрямую; индексы по created_at, executor_id, status ускоряют выборки из миллионов записей без лишних затрат.

• Exactly-once для шагов с БД
  Обычно гарантируется «по крайней мере один раз», но если шаг меняет данные в той же транзакции, что и чекпойнт, Postgres обеспечит, что изменения зафиксируются ровно один раз даже после перезапуска.

• Пользователи хвалят DBOS за простоту миграции с graphile-worker и отсутствие необходимости менять инфраструктуру.
• Сравнения с Temporal, Azure Durable Functions, Inngest, Restate и Cloudflare: DBOS выглядит проще и легче, но Temporal/Cloudflare критикуют за сложность самостоятельного хостинга и высокую цену.
• Некоторые жалуются, что «сервер» DBOS (Conductor) не open-source, что ограничивает самостоятельное развёртывание.
• Планы по добавлению Java, C#, Go и поддержке сообщества уже анонсированы; Python и TypeScript уже поддерживаются.
• Отмечена возможность комбинировать DBOS с Dagster/Oban/pgflow для более сложной оркестрации.