SQLite вместо памяти: как обуздать рост Telegram-ботов

Управляем Telegram-чаты как должно: от памяти к базе данных

Проект bot-social-publisher рос как на дрожжах. Каждый день новые пользователи подключали своих ботов, запускали кампании, развивали функционал. Но вот беда: где-то в памяти процесса валялась информация о том, какие чаты под управлением, кто их владелец, какие у них настройки. Приватный чат? Группа? Канал? Всё это было либо в переменных, либо где-то в логах.

Нужна была система. Правильная, масштабируемая, не требующая отдельного сервера для базы данных.

Первым делом посмотрел, как устроен текущий стек. В проекте уже была собственная SQLite база в data/agent.db, и там жил UserManager — отличный пример того, как правильно работать с асинхронными операциями через aiosqlite. Значит, нужно просто добавить новую таблицу managed_chats в ту же базу, скопировать философию управления пользователями и запустить в production.

Архитектурное решение было ясно с самого начала: никаких микросервисов, никаких Redis-кэшей для этого этапа. Нужна таблица с полями для chat_id (первичный ключ), owner_id (связь с пользователем), chat_type (с проверкой через CHECK constraint — только валидные типы), title и JSON-поле settings на будущее.

Неожиданно выяснилось, что индекс на owner_id — это не опциональная штука. Когда пользователь запрашивает список своих чатов, база должна найти их быстро, а не сканировать всю таблицу от начала до конца. SQLite часто недооценивают в стартапах, думают, что это игрушка для тестирования. На самом деле при правильном использовании индексов и подготовленных statements она справляется с миллионами записей и может быть полноценной боевой базой.

Реализацию сделал по образцу UserManager: создал ChatManager с асинхронными методами add_chat(), is_managed(), get_owner(). Каждый запрос параметризован — никаких SQL injection уязвимостей. Используется всё та же aiosqlite для асинхронного доступа, одна точка подключения для всей системы, без дублирования логики.

Красивый момент получился благодаря INSERT OR REPLACE — если чат переиндексируется с новыми настройками, старая запись просто заменяется. Это вышло из архитектуры, а не планировалось специально.

В итоге: одна БД, одна инфраструктура, масштабируемая схема. Когда понадобятся сложные аналитические запросы — индекс уже есть. Когда захотим добавить права доступа или расширенные настройки чата — JSON-поле ждёт. Никаких фреймворков ORM, которые обычно добавляют больше проблем, чем решают на этом этапе.

Дальше — интеграция с обработчиками Telegram API, где эта информация будет реально работать. Но то уже следующая история.

😄 Разработчик: «Я знаю ArgoCD». HR: «На каком уровне?». Разработчик: «На уровне Stack Overflow».