Распределённая платформа автоматизации браузеров, оркестрирующая ~2 500 сессий.
TKM: распределённая платформа автоматизации маркетплейса, оркестрирующая около 2 500 управляемых аккаунтов в трёх скоординированных приложениях, которые я собрал в одиночку: API на NestJS для оркестрации, React-консоль для операторов и Electron-приложение для рабочего стола, которое управляет настоящим антидетект-браузером на машине каждого оператора. Все три связывает единый контракт с типизацией через OpenAPI, поэтому изменение бэкенда, которое ломает клиент, выявляется на этапе компиляции. Основная инженерия сосредоточена в частях, которые должны выдерживать нагрузку: уникальный браузерный отпечаток для каждого аккаунта, ротация sticky-прокси с привязкой через GeoIP, прогрев сессий и планировщик, а также устойчивые пайплайны синхронизации статусов на BullMQ.
Единственный инженер на всей платформе: API оркестрации на NestJS, React-консоль для веба и Electron-приложение для рабочего стола, плюс инфраструктура и CI/CD под всем этим.
API публикует OpenAPI-контракт, который потребляют оба клиента через openapi-fetch: провод полностью типизирован от начала до конца. Изменение бэкенда, которое ломает клиент, проявляется на этапе компиляции, а не в продакшне.
Чистая модульная структура NestJS (аккаунты, прокси, заказы, отзывы, курьеры, кошельки, отчёты и другое) поверх Prisma и PostgreSQL, с BullMQ и Redis для всего асинхронного.
Интеграционные тесты на Vitest с настоящим Postgres в Docker, GitLab CI/CD и развёртывание на базе Docker.
Каждый аккаунт получает детерминированный сидированный отпечаток браузера, применяемый через CDP, с реалистичным распределением версий браузера и пятидневной ротацией плюс окном охлаждения: личности стабильны, но никогда не заморожены.
Резидентские и мобильные прокси разрешаются как sticky-сессии с привязкой к региону через MaxMind GeoIP: один уникальный IP на аккаунт с отслеживанием истории IP, чтобы два аккаунта никогда не делили адрес.
Узкое окно прогрева приоритизирует активные аккаунты, а Electron-приложение обнаруживает выходы и проходит повторную авторизацию перед началом реальной работы, вместо того чтобы падать на середине задачи.
Ограниченный параллелизм, повторные попытки и контроль лимитов запросов удерживают около 2 500 сессий без срабатывания антибот-защиты, против которой они работают.
Синхронизация статусов работает как запланированные BullMQ-задачи, обрабатывающие флот ограниченными пакетами по крону: нагрузка остаётся равномерной, а не скачкообразной.
Electron-приложение перехватывает вызовы маркетплейса через CDP и передаёт подсказки в API, который нормализует их в чистую модель заказов, позиций и пунктов выдачи.
Алгоритм FIFO-сопоставления согласует более поздние события с правильным заказом по наиболее надёжному реальному сигналу, сохраняя консистентность данных даже при неупорядоченном поступлении событий.
Успех операций оценивается с помощью доверительных интервалов Wilson, а не сырых соотношений: малые выборки не дают вводящих в заблуждение цифр.
Кроссплатформенное Electron-приложение с автообновлением и собранными в CI, подписанными Windows-релизами, публикуемыми в S3, разделяющее React-кодовую базу с веб-консолью.
Статус аккаунтов и задач передаётся в реальном времени обоим клиентам через Socket.IO; операторы видят изменения состояния без обновления страницы.
Метрики Prometheus и ротируемые логи Winston для видимости, плюс Telegram-бот для операционных рассылок и генерации отчётов в Excel и PDF.
Используют Операции на маркетплейсах, Автоматизация e-commerce.
Управляйте ~2 500 аккаунтами маркетплейса (у каждого своя личность, прокси и расписание) из одной консоли.
Electron-приложение запускает настоящий Chrome для каждого аккаунта с детерминированным ротирующимся отпечатком браузера.
Sticky резидентские и мобильные прокси, привязка к региону через GeoIP, один уникальный IP на аккаунт с историей отслеживания.
Окна прогрева сессий и планировщик, равномерно распределяющий работу по аккаунтам, чтобы не превышать лимиты запросов.
Фоновые BullMQ-воркеры согласуют состояние заказов и отзывов в единую нормализованную модель данных.
React-дашборд с таблицами на тысячи строк, фильтрами и статусами в реальном времени через Socket.IO.
Здесь намеренно нет скриншотов: это закрытый NDA-проект, ничего реального не показывается. Поэтому вот инженерия: что происходит с момента, когда Electron-приложение запрашивает сессию, до того как данные чисто приземляются в Postgres.
Electron-приложение обращается к API за сессией: личность, sticky-прокси и IP с привязкой к региону, под открытой блокировкой, чтобы два экземпляра никогда не столкнулись.
Приложение запускает настоящий Chrome с детерминированным отпечатком аккаунта через CDP, восстанавливает состояние и прогревает прокси перед реальной работой.
Работа происходит в настоящем браузере; Electron-приложение перехватывает нужные вызовы через CDP и передаёт структурированные подсказки обратно в API.
API нормализует эти подсказки в чистую модель заказов, позиций и пунктов выдачи в PostgreSQL через Prisma.
Запланированные BullMQ-воркеры согласуют более поздние состояния с правильной записью через FIFO-проход сопоставления, сохраняя консистентность данных.
Детерминированный сид для каждого аккаунта через CDP, реалистичное распределение версий, 5-дневная ротация + охлаждение.
Sticky резидентские и мобильные сессии, один уникальный IP на аккаунт, история IP отслеживается.
Привязка к региону через MaxMind, чтобы IP аккаунта оставался географически консистентным.
Узкое окно прогрева приоритизирует активные аккаунты перед реальными операциями.
Определение выхода из аккаунта и повторная авторизация перед работой, вместо падения на середине задачи.
Ограниченный параллелизм, повторные попытки и контроль лимитов запросов на ~2 500 сессиях.
Закрытый коммерческий проект под NDA. Никаких реальных аккаунтов, пользовательских данных, учётных данных или скриншотов не показывается; система описана в абстракции и визуализирована только как архитектура. Подробный разбор доступен по запросу.