В комментариях к моей предыдущей статье разгорелась интересная дискуссия о том, стоит ли принять диктуемые правила игры со стороны государства, или быть принципиальным до конца. Я решил поразгонять эти мысли и вот до чего дошел. (*Важный дисклеймер: я без претензии на истину в последней инстанции, просто захотелось поделиться самому и послушать ваше мнение)
Глупо отрицать, что разработка в Telegram сопряжена с регулярными техническими рисками в связи со сбоями и блокировками. Сегодня сообщения приходят с задержкой, завтра не загружаются файлы, а через неделю у части пользователей может перестать открываться Mini App.
При этом я уверен, что хоронить Telegram в РФ пока рано. Там остается большая аудитория, бизнес по-прежнему автоматизирует продажи и поддержку, разработчики получают проекты. Но проектировать бота как систему, которая целиком держится на одном мессенджере, уже опасно.
Прогноз на 2026–2027 годы
Скорее всего, Telegram ждет период нестабильного доступа: локальные сбои, медленная доставка контента, проблемы с медиа и постепенный отток части пользователей. Или количество пользователей сохранится, но заходить будут реже. Полное одновременное отключение выглядит менее вероятным, хотя закладываться стоит и на такой вариант.
Боты тоже точно никуда не исчезнут. Но вот боты-визитки с парой кнопок будут нужны все реже. Ценность сместится к разработчикам, которые умеют вынести данные и бизнес-логику за пределы Telegram, подключить веб-интерфейс, CRM или другой мессенджер
Что стоит изменить в архитектуре уже сейчас
Вынести данные за пределы Telegram
Telegram ID лучше хранить как идентификатор канала связи. Рядом должен быть внутренний user_id, а при согласии пользователя еще и телефон или email.
Внешняя база данных помогает восстановить работу после сбоя, собрать аналитику и перевести людей в другой канал.
Отделяйте сценарии от команд и кнопок
Условия, статусы, платежи и переходы должны жить в отдельном слое приложения. Тогда Telegram остается интерфейсом, а не местом, где спрятана вся логика продукта.
Один и тот же пользовательский путь можно будет подключить к Telegram, личному кабинету на сайте, мобильному приложению или API. Это требует больше работы на старте, зато потом избавляет от болезненного переписывания.
Делайте обработчики идемпотентными
Повторное обновление не должно второй раз создавать заказ, начислять бонусы или отправлять заявку. Для этого понадобятся:
уникальные идентификаторы операций;
очередь событий;
повторные попытки с увеличением интервала;
журнал обработки;
дедупликация сообщений и контроль статусов.
Эта часть обычно кажется скучной, пока однажды не приходит десять одинаковых апдейтов и система не оформляет клиенту десять заказов.
Заранее выберите резервный канал для связи
Резервом может стать веб-кабинет, email, SMS, телефонная поддержка, мобильное приложение или другой мессенджер. Выбор зависит от сценария: интернет-магазину нужен доступ к заказу, сервису поддержки — возможность принять обращение, образовательному проекту — стабильная рассылка и кабинет ученика.
Особое внимание уделите тестам
Полезно периодически отключать отдельные части системы в тестовой среде и смотреть, что произойдет, если:
webhook перестал отвечать;
внешнее API работает медленно;
нельзя загрузить файлы;
обновления приходят повторно;
временно недоступна база данных;
Telegram не открывается у части пользователей.
После таких проверок обычно находятся дыры в самых неожиданных местах
Как подготовить бота к ограничениям
Начните с аудита зависимостей. Обычно в списке оказываются:
Telegram Bot API;
Telegram Login;
Mini App;
платежные сервисы;
CDN и хранилища файлов;
внешние таблицы и базы данных;
webhook-инфраструктура;
аналитика и сервисы уведомлений.
Для каждой зависимости нужны таймаут, понятное поведение при ошибке и процедура восстановления. Если webhook недоступен, система должна иметь запасной способ получить обновления. Если упал платежный сервис, заказ лучше сохранить и сообщить пользователю, что оплата будет подтверждена позже.
Если все-таки мы говорим о конструкторах…
В конструкторе, с которым я периодически работаю, сценарии можно строить через команды, условия, переменные и действия, а данные клиентов выводить в таблицы или внешнюю систему по API.
Но самый большой «бонус» — это то, что у них можно создавать бот одновременно в Telegram и в МАХ. Прям в одном кабинете и это очень удобно не только разработчику, но и бизнесу/эксперту, который заказывает бот.
Кстати, таких конструкторов несколько, и у каждого свои плюсы и минусы, как обычно. Если тема актуальна, напишите в комментах, и я сделаю обзор
Если же все-таки мы рассматриваем крайний вариант с полной блокировкой Telegram: что делать бизнесу?
В первую очередь нужно:
Сохранить контакты клиентов и данные, которые бизнес имеет право хранить.
Выгрузить необходимые сведения из Telegram и связанных сервисов.
Подготовить страницу статуса с понятными инструкциями.
Открыть альтернативный вход в личный кабинет или поддержку.
Проверить резервные каналы уведомлений.
Telegram может оставаться главным каналом. Но доступ к заказам, оплате и данным клиентов не должен зависеть только от него.
Что делать разработчику
Разработчику стоит заранее обсудить с клиентом сценарий восстановления, настроить мониторинг, экспорт данных и резервные способы связи. Ни в коем случае не давать необоснованных обещаний, что сможешь починить все за час. Это звучит бодро, но в момент, когда все горит, мало кого спасает.
Полезнее развивать навыки в backend-разработке, API-интеграциях, очередях сообщений, базах данных, мониторинге, логировании, платежных системах и миграции данных. Особенно ценится умение собрать продукт, который переживет отказ одного канала без потери заказов и клиентов.
Куда двигаться разработчику Telegram-ботов
Зависит от конечной цели.
Можно развиваться в разработке в конструкторе, который поддерживает не кольцо мессенджеров. Так как в полную блокировку я все-таки не очень верю, а изучить работу конструктора намного проще, чем кодить. При этом код никто не мешает учить параллельно
Или уйти в системную разработку. Гораздо ценнее (но и сложнее) умение спроектировать бота как часть большой системы: очереди, интеграции с CRM и платёжными сервисами, обработка данных, масштабирование под нагрузку. Это тот самый навык, который не обнуляется, если завтра снова все поменяется
Самое главное: создавать бизнес-логику, которую можно подключить к нескольким интерфейсам. В такой архитектуре Telegram становится одним из каналов работы с пользователем. Удобным, привычным, часто основным, но не единственным.
Итог
Telegram, вероятно, сохранит большую аудиторию в России и в 2026–2027 годах. При этом зависимость от него будет стоить бизнесу все дороже.
Отказываться от Telegram прямо сейчас никто не готов 100%. Гораздо разумнее подготовиться: вынести данные во внешнее хранилище, отделить бизнес-логику от интерфейса, настроить очереди и мониторинг, собрать контакты пользователей, предусмотреть запасной канал
