Автоматизация без готового оркестратора: как я собрал MVP на своей архитектуре

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

Почему n8n выпал из стека

Вся моя система держится на интеграциях с нишевыми сервисами: TGStat и Telemetr.io для аналитики каналов, Telega.in и TeleTarget для закупа, VK маркет-платформа для рекламы, ОРД для маркировки. Я проверил каждый: готовой ноды в n8n нет ни для одного. Значит, любую из этих интеграций я всё равно пишу руками — HTTP-запросы, парсинг ответов, обработка ошибок — внутри Code-ноды.

Тут и вскрылась подмена. Я думал, что беру n8n ради готовых блоков, но под мои задачи готовых блоков не существует. Оставался только визуальный слой: стрелочки между узлами и веб-интерфейс. За этот интерфейс я платил бы отдельным сервисом на VPS, который надо обновлять, бэкапить и держать в памяти. Код при этом всё равно мой, просто спрятанный в текстовые поля веб-редактора, где его неудобно версионировать и невозможно нормально тестировать.

Получилась обёртка вокруг моего же кода. Она усложняет отладку и добавляет точку отказа. Для соло-проекта обмен так себе.

Что я поставил вместо

Я заменил n8n тонким оркестратором на Python. Ядро — машина состояний, которая хранит своё состояние в Postgres. Никакой магии: таблица с задачами, у каждой задачи есть текущий статус, входные данные и результат. Оркестратор в цикле смотрит, какие задачи готовы к следующему шагу, дёргает нужную функцию-интеграцию и записывает результат обратно.

Postgres в роли хранилища состояния выбрал по четырём причинам. Очередь или отдельный движок workflow тут были бы лишними:

• База у меня в проекте уже есть, данные по каналам и закупам всё равно лежат там;
• Состояние процесса переживает перезапуск контейнера без дополнительных настроек;
• Я вижу, что происходит, обычным SQL-запросом, без чтения логов чужого движка;
• Транзакции дают честную гарантию, что задача не потеряется и не выполнится дважды.

Весь стек живёт в Docker Compose. Один контейнер — оркестратор, второй — Postgres. Интеграции лежат обычными Python-модулями рядом с оркестратором, каждый со своими функциями под конкретный API. Добавить новый сервис — значит написать модуль и подключить его к машине состояний, без нового узла в чужом UI.

Как выглядит схема

Если рисовать компоненты, получается четыре слоя.

1. Слой интеграций. Тонкие клиенты к TGStat, Telemetr.io, Telega.in, TeleTarget, VK и ОРД. Каждый умеет только свои запросы и ничего не знает про общую логику.
2. Слой оркестрации. Машина состояний: читает задачи из Postgres, решает, какой шаг делать дальше, вызывает нужную интеграцию, ловит ошибки и складывает результат обратно.
3. Слой хранения. Postgres как единый источник правды — и для бизнес-данных, и для состояния процессов.
4. Слой запуска. Docker Compose связывает контейнеры, задаёт переменные окружения и поднимает всё одной командой.

Поток простой: приходит новая задача (например, «проверить канал и решить по закупу»), оркестратор проводит её через шаги — аналитика, оценка, размещение, маркировка в ОРД — и на каждом шаге фиксирует прогресс в базе. Упал сервис на третьем шаге — задача остаётся в своём статусе и повторяется с этого места. С нуля начинать не нужно.

Фазовый план

Сборку я разбил на фазы, чтобы на каждом этапе была работающая версия.

• Фаза 1. Postgres и схема таблицы задач. Оркестратор, который умеет читать задачу, менять статус и логировать. Одна интеграция-заглушка вместо реального API — проверяю, что цикл крутится.
• Фаза 2. Подключаю аналитические интеграции (TGStat, Telemetr.io). Задача проходит первый реальный шаг и записывает данные по каналу.
• Фаза 3. Добавляю закуп (Telega.in, TeleTarget) и VK. Появляется полная цепочка от аналитики до размещения.
• Фаза 4. ОРД и маркировка, обработка ошибок, повторы. Здесь система становится пригодной для реальной работы.

Что я вынес из этого

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

Моё решение не универсальное. Работай я со стандартными сервисами вроде Google Sheets, Slack или почты — n8n забрал бы кучу рутины, и я оставил бы его без раздумий. Проверьте свой список интеграций до того, как ставить оркестратор: посчитайте, сколько шагов реально закрыты готовыми нодами. Если большинство придётся кодить руками — тонкий свой оркестратор выйдет проще и понятнее.