Одна БД для всех: как мы добавили чаты без архитектурного хаоса

Одна база на всех: как мы добавили управление чатами без архитектурного хаоса

Когда проект растёт, растут и его аппетиты. В нашем Telegram-боте на основе Python уже была отличная инфраструктура — UserManager для управления пользователями, собственная SQLite база в data/agent.db, асинхронные запросы через aiosqlite. Но вот беда: чат-менеджер ещё не появился. А он нам был нужен.

Стояла вот какая задача: нужно отслеживать, какие чаты управляет бот, кто их владелец, какой это тип чата (приватный, группа, супергруппа, канал). При этом не создавать отдельную базу данных — это же кошмар для девопса — а переиспользовать существующую инфраструктуру.

Первым делом заглянул в текущую архитектуру. Увидел, что всё уже завязано на одной БД, один конфиг, одна логика подключения. Идеально. Значит, нужна просто одна новая таблица — managed_chats. Задумал её как простую структуру: chat_id как первичный ключ, owner_id для связи с пользователем, chat_type с проверкой типов через CHECK, поле title для названия и JSON-колонка settings на будущее.

Обычно на этом месте разработчик бы создал абстрактный ChatRepository с двадцатью методами и паттерном Builder. Я же решил сделать проще — скопировать философию UserManager и создать классический ChatManager. Три-четыре асинхронных метода: добавить чат, проверить, управляется ли он, получить владельца. Всё на aiosqlite, как и везде в проекте.

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

Интересный момент: SQLite часто недооценивают в стартапах, думают, что это игрушка. На самом деле она справляется с миллионами записей, если её правильно использовать. Индексы, PRAGMA для оптимизации, подготовленные statements — и у вас есть боевая база данных. Многие проекты потом переходят на PostgreSQL только потому, что привыкли к MySQL, а не из реальной нужды.

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

Следующий шаг — интегрировать это в обработчики событий Telegram API. Но это уже другая история.

😄 Почему база данных никогда не посещает вечеринки? Её постоянно блокирует другой клиент!