Архитектура Telegram-бота с мини-приложением

Разбор лекции Ивана Балашова от 22 октября 2026 года из библиотеки стримов Guide DAO.

Это вторая лекция цикла Ивана о системном дизайне. В первой части он разложил сервис записи к барберу на роли, сущности и слои, а Claude составил по этой схеме план. Пока шла новая лекция, агент дописывал по плану Telegram-бота на Python, один бот для одного мастера. Теперь Иван смотрит на систему целиком: где живёт логика, из каких компонентов состоит бот и что изменится, когда рядом появится мини-приложение. Без этого, по словам Ивана, агента трудно держать в узде.

Схемы Иван по-прежнему рисует прямоугольниками и стрелками в Excalidraw. Для них есть язык UML, международный стандарт проектирования, и в серьёзной разработке без его диаграмм не обойтись. Но UML изучают отдельным университетским курсом, у Ивана он шёл целый семестр, поэтому разбирать его Иван пока не стал.

Веб-приложения Иван делит на два типа: толстый клиент с тонким сервером и тонкий клиент с толстым сервером. Клиентом называют то, с чем взаимодействует пользователь: сайт, мобильное приложение, приложение на телевизоре, компьютерную игру. Клиент обращается к серверу, то есть к бэкенду.

Толстый клиент Иван показал на самом Excalidraw. Он открыл в браузере инструменты разработчика, вкладку Network, и стал добавлять на доску прямоугольники. На бэкенд не ушло ни одного запроса. Вся логика рисования живёт на клиенте, а сервер, скорее всего, хранит только сессию и состояние доски.

Для обратного примера Иван взял условное приложение банка. Перевод другу или между своими счетами проводит не приложение в браузере или телефоне, а сервер. Клиент отправляет запрос на операцию, сервер её выполняет, а на клиенте остаются красивые кнопки и переходы между экранами. Telegram-бот устроен так же. Клиентом служит само приложение Telegram, а вся логика живёт на бэкенде. По такой схеме сделано большинство веб-приложений, и Иван считает её самой удобной, потому что сервер сам решает, как обработать каждый бизнес-сценарий.

При проектировании, по словам Ивана, важно не получить толстый клиент вместе с толстым сервером, когда часть бизнес-логики живёт у пользователя, а часть на сервере. Тогда сделать новую фичу невероятно сложно. Допустим, валидация полей есть только на клиенте, а вы хотите её поправить или переиспользовать. Если клиентом служит мобильное приложение, ради такой правки придётся выпускать отдельный релиз.

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

С тонким клиентом ограничений по железу почти нет. Arduino может отправить данные хоть сырыми, а разберётся с ними мощный сервер, только его придётся арендовать. В первой схеме самый дешёвый сервер за 500 рублей в месяц спокойно держит 100, а то и 1000 пользователей в день. Во второй его может не хватить, потому что все запросы выполняются на сервере. Если у него одно ядро и нет многопоточности, запросы начнут тормозить, а пользователи будут жаловаться, что всё лагает.

Бот для записи к барберу Иван строит по второй схеме. Свой клиент писать не нужно, его благополучно даёт Telegram, так что остаётся серверная часть.

Кроме клиента, то есть приложения Telegram, на схеме два компонента: бот на Python и база данных. Telegram и бот обмениваются запросами, и стрелка между ними двусторонняя. Стрелку к базе Иван нарисовал односторонней: бот ходит в базу за данными, а сама база на бота никак не влияет. Для работы этого достаточно.

Дальше Иван провёл мысленный эксперимент. Допустим, бот должен приносить больше лидов, а пользоваться им стало неудобно, и рядом появляется мини-приложение Telegram, которое Иван называет Telegram Web App. У него стрелка только одна. Мини-приложение само ходит на сервер, а бот написать в него не может, разве что через веб-сокеты. Обрабатывать такие запросы нынешний бот не умеет, механика у двух клиентов разная.

Если спросить Claude, что делать, он, по словам Ивана, предложит доработать бота, чтобы тот обслуживал и мини-приложение. Получится одно приложение на одном сервере с одним деплоем. Иван уверяет, что это не шутка: если далеко масштабироваться не нужно, он бы и сам начал с этого. Цена решения видна, когда приложение падает. Отваливаются сразу оба клиента, и записаться нельзя ни через бота, ни через мини-приложение.

В более серьёзном проекте, почти уверен Иван, у бота и мини-приложения были бы отдельные бэкенды. Упал бот, мини-приложение продолжает работать, и наоборот. Такой подход называют BFF, Backend for Frontend. Переходить на него Иван предлагает, когда клиенты бота начинают мешать клиентам мини-приложения. Тогда мини-приложение выносят в отдельное приложение на отдельном сервере.

Получается почти распределённая система, но к падениям она устойчива не до конца. Точкой отказа остаётся база данных: ляжет она, и снова не работают оба приложения. Если сервис станет мегапопулярным и база перестанет справляться, следующим шагом будет репликация, то есть копии базы, между которыми распределяют запросы. Такие подсказки можно спрашивать у Claude, но Иван советует и самому почитать, как это работает.

Зачем всё это, если хочется просто вайбкодить? Вопрос Иван считает валидным. Базовые вещи вроде толстого и тонкого клиента он советует понять уже сейчас, они несложные. Проектирование высоконагруженных распределённых систем можно разобрать с Claude и лекциями за пару недель, но только тогда, когда понадобится.

Тема огромная. Паттернов там очень много, о распределённых системах написано множество книг, а в зарубежных вузах, как думает Иван, системный дизайн проходят отдельным семестром.

Совсем без основ всё же не обойтись. Любое приложение получает данные от клиента, что-то с ними делает и куда-то сохраняет, так что база данных появляется почти сразу. SQL-баз, по прикидке Ивана, около десятка, среди них PostgreSQL, MySQL и SQLite. NoSQL-баз тоже много, например Redis и Cassandra. Глубоко погружаться в них не обязательно, но надо быть готовым, что эти инструменты однажды выстрелят. Для бота записи к барберу Иван на старте взял бы SQLite, потому что PostgreSQL тут не нужен. Claude же при проектировании решил, что без PostgreSQL никуда.

К концу лекции Claude закончил работу, и Иван открыл проект в VS Code. Слоёный пирог из плана на месте: папка bot отвечает за отображение, database за хранение данных, domain за бизнес-логику. Файлы actions.py и menu.py в bot обрабатывают действия на экране и рисуют меню, бизнес-логики в них нет. Файлы в папке repositories один к одному ложатся на таблицы и состоят из запросов к базе. В domain живёт класс BookingService, который отдаёт свободные дни и слоты, создаёт, подтверждает, отменяет и переносит записи.

Потом Иван ненадолго прервал трансляцию, чтобы вписать токен бота и свой Telegram ID, и бот заработал. Иван зашёл в него как мастер: расписание, шаблон недели, все дни пока выходные. Рабочие часы бот просит ввести текстом в виде интервала. Иван честно признал, что это не очень удобно, но часы на вторник добавил, а следом завёл тестовую услугу на 30 минут за 1000 рублей. С задачей Claude справился, а PostgreSQL, судя по всему, поднял в Docker-контейнере.

Под конец Иван назвал две вещи, которые стоит понимать самому. Первая касается архитектуры внутри приложения, в которой не должны путаться ни вы, ни агенты. Хитрую архитектуру просить у Claude не нужно.

От вас требуется понимать концепции, на которых она стоит. Вторая вещь касается разницы между тонким и толстым клиентом. Не скажете Claude, что у вас есть бэкенд, или забудете дать ему этот бэкенд в контекст, и приложение начнёт рассыпаться после первых же доработок. Такое Иван видел не раз.

Архитектурную мышцу, по словам Ивана, программисты качают десятилетиями. Следующую лекцию он обещал посвятить базам данных, чтобы, когда Claude напишет «здесь нужен Redis», вы понимали, что это и зачем.

Один слушатель пожаловался, что его бот остановился: бесплатно продлевать время на сервере больше нельзя. Бесплатных серверов Иван не посоветовал, потому что честно не знает таких. Сам он, кажется, ни месяца не жил без своего сервера для экспериментов и советует платные варианты. Найти сервер можно и за 350 рублей, а Telegram-боту хватит простого сервера рублей за 500. Сервер за 20, 30 или 40 тысяч рублей для такой задачи не нужен.

В высоконагруженной системе база живёт на одном сервере, приложение на другом. Когда пользователей становится больше, серверов для бэкенда будет два, а перед ними встанет nginx и распределит нагрузку. Всё это нужно, только когда появились пользователи, которые приносят деньги.

Держать сервер дома на роутере можно, но после перезагрузки роутер получит новый IP-адрес, так что понадобится провайдер со статическим IP. Для Telegram-бота это не проблема, его можно поднять хоть на роутере, хоть на Raspberry Pi, хотя арендовать сервер, по мнению Ивана, дешевле, чем купить Raspberry Pi. В схеме long polling бот сам ходит в Telegram API, поэтому постоянный адрес ему не нужен. Во второй схеме Telegram сам приходит в приложение через вебхуки. Тогда статический IP нужен, зато нагрузка на сервер сильно меньше.

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

Когда просите агента о новой фиче, прямо скажите, где у вас бэкенд, и дайте ему этот код в контекст.

Прикиньте нагрузку. С тонким клиентом всю работу делает сервер, но небольшому Telegram-боту хватит сервера за 500 рублей в месяц.

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

Проверяйте выбор агента. Claude поставил PostgreSQL туда, где на старте хватило бы SQLite.

Для бота в режиме long polling статический IP не нужен, так что подойдёт дешёвый сервер. Вебхукам постоянный адрес понадобится, зато нагрузка на сервер будет ниже.