Scaling Telegram Bots: ChatManager Tames Permission Chaos

Building ChatManager: Taming the Telegram Bot Zoo

Pavel’s voice agent had a problem that whispers into every bot project eventually: chaos. The system was humming along fine with SQLite handling user data, but now the bot needed something more nuanced—it had to know which chats it actually owned and enforce strict permission boundaries around every command. The ChatManager capability existed in a private bot somewhere, but nobody had ever integrated it into this production system. That’s where the real work began.

The goal sounded deceptively simple: extract the ChatManager class, wire it into the existing codebase, set up database infrastructure to track which chats belonged to which owners, and validate it all with tests. But this wasn’t greenfield work. It meant fitting new pieces into a system that already had strong opinions about logging patterns, database access, and middleware architecture. Getting this wrong would mean either breaking existing functionality or creating technical debt that would haunt the next sprint.

Pavel started by mapping the work into five logical checkpoints—each one independently testable. First came the infrastructure layer: he pulled the ChatManager class from the private bot and integrated it with the project’s existing structlog setup. Rather than adding another logging dependency, he leveraged what was already there. The real win came with the async database choice: aiosqlite wrapped every SQLite operation in asyncio, ensuring that database calls never blocked the main message-processing loop. This is the kind of detail that separates “works” from “works under load.”

Next came the migrations. Pavel created a managed_chats table with proper schema—tracking chat IDs, their Telegram types (private, group, supergroup, channel), and ownership relationships. He added indexes strategically and created a validation checkpoint: after each migration ran, a quick query confirmed the table existed and was properly structured.

Then came the middleware. Before any handler could touch a managed chat, a permission layer would intercept requests and verify that the user ID matched the chat’s owner record. Clean separation of concerns. The command handlers followed naturally: /manage add to register a chat, permission middleware to silently reject unregistered operations.

Here’s something most developers don’t think about until they hit the wall: why async SQLite matters. SQLite is synchronous by default, and when you throw it into an async application, it becomes a chokepoint. Every database query blocks your entire bot’s event loop. Wrapping it with aiosqlite costs almost nothing—just a thin async layer—but the payoff is immediate. The bot stays responsive even when the database is under load. It’s one of those architectural decisions that feels invisible until you forget it, then your users complain their commands time out.

After the integration came the validation. Pavel wired the handlers, wrote unit tests against the new permission logic, and confirmed that unauthorized users got silent rejections—no error spam, just the bot calmly declining to participate.

The result: a bot that now knows exactly which chats it owns, who controls it, and enforces those boundaries before executing anything. The architecture scales too—future versions could add role-based access, audit trails, or per-chat configuration without touching the core logic.

Production deployment came next. But that’s already tomorrow’s problem.

😄 Why did the database architect bring a ladder to the meeting? Because they wanted to take their schema to the next level.