SQLite спасает день: масштабируемая БД вместо хаоса в памяти

SQLite вместо памяти: как я спас Telegram-ботов от хаоса

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

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

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

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

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

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

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

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

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

😄 Разработчик говорит: «Я знаю SQLite». HR: «На каком уровне?». Разработчик: «На уровне, когда она работает, и я этому не верю».