Продолжение технической серии про «Скачай просто» — в этот раз про архитектуру, а не про антибот-защиту конкретных площадок.
Схема простая на бумаге и не такая простая в деталях: Telegram-бот принимает ссылку, ставит задачу в очередь, воркер её выполняет и отдаёт результат обратно в чат. У нас это три отдельных Docker-образа — bot, worker и miniapi (мини-веб-приложение для админки), задачи между bot и worker идут через Celery-очередь (download_media, download_audio). Разделение важно по двум причинам: во-первых, тяжёлая работа (скачивание, конвертация) не блокирует обработку входящих сообщений бота; во-вторых, bot и worker можно масштабировать и деплоить независимо.
Грабля, в которую мы наступили сами: bot и worker — это два разных образа, которые в момент деплоя какое-то время могут работать на разных версиях кода. Если добавить воркеровской задаче новый обязательный параметр и задеплоить сначала bot — новый bot начнёт вызывать задачу с параметром, которого старый worker ещё не знает, и задача упадёт с TypeError ещё до попытки повтора. Решение — простое правило: новые параметры задач всегда добавляются как keyword с default-значением, а сам деплой идёт в порядке worker → bot, не наоборот.
Rate limiting держится на Redis — без него параллельные запросы от одного пользователя (или спам-атака) быстро кладут очередь. Хранилище состояния — SQLite для небольшой нагрузки с возможностью перейти на Postgres без переписывания SQL-запросов (у нас есть общая абстракция для плейсхолдеров запросов, работающая в обе стороны).
Мониторинг — не логи "постфактум", а активный процесс на APScheduler: фоновая джоба каждые 5 минут проверяет здоровье бота (крашится ли, отвечает ли), плюс отдельная система alert'ов с уровнями severity (info/warning/critical), которая шлёт уведомление владельцу в Telegram при аномалиях — например, при резком росте доли неудачных скачиваний за 15-минутное окно. Есть и safe mode: если ошибки скачивания резко скачут вверх, бот автоматически переключается в режим "только для владельца", чтобы не сыпать ошибками на реальных пользователей, пока не разберутся в причине.
Показательный урок последней недели: свежий алерт про диск (80%+ занято) привёл не туда, куда ожидалось — не временные файлы скачиваний виноваты (там всего пара сотен мегабайт), а накопившийся Docker build cache, который на каждой пересборке образов растёт и растёт, если его не чистить. На сервере с 1 CPU / 1.8 GB RAM (да, весь стек — bot, worker, miniapi, redis — крутится на одной такой VPS) это ощущается быстро.
Метрики, за которыми реально стоит следить в проде маленького сервиса: не абсолютное число ошибок, а их доля за короткое окно (15 минут показательнее, чем сутки — аномалия видна быстрее), плюс отдельно долю fallback-срабатываний по площадкам — это ранний индикатор, что конкретная платформа поменяла защиту раньше, чем это заметят пользователи через тикеты.
YouTube 
Telegram 
Website 
