Два сервиса, одна сессия, ноль работающих
👁 611↗ 2💬 6
У MindPost было две жизни. Первая - AI-редактор в стиле Notion + Cursor, с чатом, с интеграциями Claude, OpenAI, DeepSeek. Вторая - когда я выпилил всё лишнее и оставил MCP-коннектор для Claude AI. Под капотом тут MTProto для доступа к данным Telegram-каналов.
Работало отлично. Пока я не решил сделать Telegram-бота.
Идея бота простая: пользователь подключает свой канал, бот анализирует тон оф войс и генерирует посты в его стиле. Бот тоже работает через MTProto. Через тот же файл сессии. И вот тут начались проблемы.
MTProto не рассчитан на два клиента с одной сессией. Сервисы начали выбивать друг друга: один подключается - потому перезаписывает файл сессии - второй об этом не знает и отваливается. Бот работает - MCP падает. MCP поднимается - бот падает. И так по кругу.
Два варианта решения:
Первый - разделить сессии. Каждый сервис получает свою сессию. Быстро, но с последствиями: дублирование логики подключения, два файла сессий, два места где может сломаться MTProto, и оба нужно поддерживать отдельно, но в тоже время полная изоляция и можно масштабировать независимо оба сервиса.
Второй - выделить MTProto в отдельный микросервис. Один процесс держит сессию, одна база данных, кэширование одинаковых запросов, рейт-лимиты для Telegram API, ленивая подгрузка обновлений. Остальные сервисы ходят к нему через REST API.
Я выбрал второй.
Что получил:
Универсальный сервис, который можно переиспользовать. Любой новый проект, которому нужны данные из Telegram - просто подключается к REST API. Не нужно знать про MTProto, сессии, лимиты. Всё инкапсулировано.
Чем заплатил:
Единая точка отказа. Если mtproto-service падает - падает всё, что от него зависит. И нужно следить за обратной совместимостью: каждый релиз этого сервиса нужно проверять, чтобы не сломать продакшн для MCP и бота одновременно. Одно неосторожное изменение в API - и два сервиса лежат.
Это классический trade-off, который существует в разработке десятки лет. Дублирование vs единая точка отказа. DRY vs устойчивость. В учебниках правильный ответ - "зависит от контекста". В реальности - зависит от того, что болит прямо сейчас. У меня болело дублирование и гонка за одну сессию. Поэтому я выбрал микросервис и принял его риски.
А если mtproto-service упадёт? Об этом в следующих постах.
Telegram | YouTube | Запретграм
61
Комментарии · 6
- @sunm8а зачем ты коннектишь сессию для чтения тг канала для анализа?
- А как ты делаешь?
- @sunm8
- @sunm8не я то делаю постоянный париснг, по этому мне нужно читать тг каналы в онлайн режиме. у меня запрос другой а для одного чтения инфы думаю достаточно через веб инфу подтянуть просто ссылку открыть и прочитать это ж легче, и API и MTProto лишний раз не дергаешь
- Ну это несерьезно) там же куча ограничений. Выгрузка по 20 постов, плюс телега может еще капчу показать из-за частых запросов. Это не те костыли к которым надо идти, когда есть рабочий вариант с MTProto. Но у mtproto тоже есть ограничения свои и риски, о которых кстати ты писал, но лучше с этим работать, а не писать веб-парсер
- @sunm8ну если поток не большой и в целом лимиты использовать то наверное да. но опять же - у меня были и лимиты и вейтеры и прочие штуки для эмуляции живого человека но видимо не хватило добавлял после недавних событий)