Как один блогер сломал нам бота и сжёг 1400 лидов за 20 минут: жесткий урок масштабирования

Тот самый ноябрьский звонок

В ноябре 2022 года я выпил слишком много эспрессо и чуть не бросил IT. Наш клиент — магазин спортивного питания — запускал рекламную интеграцию у блогера-миллионника. Мы написали систему, где телеграм бот прием заявок обрабатывал прямо в базу данных, шнырял в CRM и отдавал ссылку на оплату. Проект казался банальным: Python, библиотека aiogram, сервачок за пару тысяч рублей в месяц. Мы проверили его на сотне тестовых кликов. Всё летало.

В 19:00 блогер выложил сторис. В 19:03 телефон разрывался от уведомлений Sentry.

За первые три минуты в бота прилетело 4 200 пользователей. Не за день. За три минуты. База данных SQLite тупо заблокировалась на запись. Телеграм начал присылать повторные вебхуки, потому что наш сервер не успевал отвечать за отведенные Telegram API 5 секунд. Возникла рекурсивная лавина: бот пытался обработать старый запрос, получал дубль, снова лез в закрытый файл базы и падал с таймаутом. Людям приходили по три ссылки на оплату, с них списывались деньги, а менеджеры в CRM видели только белый экран. Мы потеряли около 1400 горячих клиентов и чуть не попали на судебный иск.

Анатомия катастрофы: где ломается кастомный бот

Этот провал стоил нам 300 тысяч рублей компенсации клиенту и недели бессонных ночей. Но он же навсегда выбил из моей головы иллюзию, что чат бот разработка — это просто «накидать код по туториалу с YouTube».

Когда вы заказываете бот для бизнеса телеграм, вам почти никогда не говорят про крайние сценарии (edge cases). Подрядчик показывает красивое меню, тестирует его в одиночку и сдает работу. А потом наступает реальность.

Вот три точки, где рушится большинство систем, если их делали без понимания нагрузки:

1. Синхронная блокировка Event Loop. Вы запускаете асинхронный фреймворк, но внутри одного хэндлера вызываете медленный сторонний API (например, отправляете запрос в эквайринг или проверяете остаток на складе). Пока один юзер ждет ответа 2 секунды, остальные 500 человек стоят в глухой очереди. Бот выглядит мертвым.

2. Отсутствие очередей (Message Queue). Сервер должен принимать вебхук от Telegram, моментально отвечать кодом 200 OK и сбрасывать задачу в брокер — Celery или Redis. Если обработка логики идет прямо в процессе вебхука, при скачке трафика Telegram начнет бомбардировать вас повторными запросами, считая, что ваш сервер умер. Это классический DDoS своими же руками.

3. Двойной клик и состояние гонки (Race Condition). Пользователь жмет кнопку «Оплатить», ничего не происходит полсекунды, и он панически нажимает её еще пять раз. Без жестких блокировок по ID пользователя в Redis бот сгенерирует пять транзакций. Поверьте, разбираться с разъяренным клиентом, у которого списалось 15 000 рублей вместо 3 000 — сомнительное удовольствие.

Конструкторы против кода: иллюзия дешевизны

После той аварии мы полностью переписали архитектуру. Но ко мне до сих пор приходят предприниматели со словами: «Зачем нам телеграм бот на заказ, если есть конструкторы за 500 рублей в месяц?». Или вспоминают какой-нибудь готовый бот максим для бизнеса или типовые no-code платформы.

Я не против конструкторов. Если вам нужен простой чат бот для бизнеса и блога с визиткой на три кнопки — собирайте на конструкторе. Это быстро. Но как только появляется сквозная аналитика, сложные сценарии, гибкие оплаты или параллельный whatsapp бот для бизнеса с единой базой — конструкторы превращаются в ад. Вы упираетесь в лимиты, не можете обработать ошибку платежной системы, а при падении стороннего сервиса ваш отдел продаж просто сидит без работы.

Сложная автоматизация требует изолированной логики. Сегодня бизнес хочет больше, чем просто кнопки. Пошел тренд на ai бот для бизнеса — когда в диалог вшивают нейросеть для квалификации лидов, или голосовой бот для бизнеса, который сам перезванивает после брошенной корзины. Прокинуть OpenAI API через конструктор можно за полчаса, но заставить его не «галлюцинировать» скидками в 99% при 500 одновременных диалогах — это сложная инженерная задача.

Что проверять до запуска трафика

За годы работы я выработал правило: считать, что упадет абсолютно всё. Если вы планируете внедрять чат бот для бизнеса телеграм, требуйте от разработчиков ответа на четыре вопроса:

Во-первых, где живут задачи? Если в проекте нет Redis или RabbitMQ для управления очередями, при первом же наплыве трафика систему заклинит.

Во-вторых, как обработан статус «пользователь заблокировал бота»? Если бот пытается отправить рассылку или статус заказа юзеру, который нажал Stop, Telegram вернет ошибку. Неправильная обработка этой ошибки может положить весь поток рассылки.

В-третьих, изолированы ли платежи? Состояние заказа должно меняться только по идемпотентному webhook от платежного шлюза, а не по нажатию кнопки в чате.

И в-четвертых, есть ли fallback-сценарий? Если отвалится CRM, сохранит ли бот прием заявок в локальную резервную БД или хотя бы отправит копию в закрытый инженерный канал?

Честный взгляд на разработку

Хорошая команда отличается от неопытного фрилансера не тем, что у нее никогда ничего не ломается. Настоящий опыт — это когда ты точно знаешь, *где именно* система попробует умереть под нагрузкой, и заранее подстилаешь соломку.

Мы в GuardLabs набили эти шишки на реальных деньгах и чужих нервах еще пару лет назад. Сейчас мы собираем отказоустойчивые Telegram-боты под ключ (лиды, оплаты, автоответы) с нормальной архитектурой, очередями и защитой от пиковых нагрузок — без детских болезней и падающих баз данных. Если вам нужна надежная система для продаж, а не мина замедленного действия перед запуском трафика, заходите к нам, обсудим задачу по-человечески.

Originally posted at https://guardlabs.online/articles/telegram-bots-freelance-202607.html