Telegram-бот на Python (aiogram 3): архітектура, БД, деплой 2026
Бот на кілька команд пишеться за вечір в одному файлі. Проблеми починаються, коли він виростає до кількох десятків сценаріїв. Розберемо структуру, яка це витримує.
Розділення на шари
Обробники повідомлень, бізнес-логіка й доступ до даних мають лежати окремо. Обробник приймає повідомлення й викликає сервіс - уся логіка всередині обробника перетворює проєкт на кашу за місяць.
Тексти повідомлень виносьте окремо. Це і спрощує правки, і робить можливою багатомовність без переписування.
Стан діалогу
Для багатокрокових сценаріїв потрібна машина станів. Зберігати стан у пам'яті процесу можна тільки для прототипу: після перезапуску всі активні діалоги обірвуться.
Для робочого проєкту стан зберігається у зовнішньому сховищі, щоб перезапуск бота був непомітним для користувача.
База даних
Реляційна база під структуровані дані: користувачі, замовлення, стани. Не намагайтесь зберігати все в одній таблиці з полем-звалищем.
Обов'язково версіонуйте схему через міграції. Ручні зміни структури на робочому сервері рано чи пізно закінчуються втратою даних.
Деплой
Для більшості ботів достатньо невеликого сервера з контейнером і автоматичним перезапуском. Вебхуки надійніші за постійне опитування при помітному навантаженні.
Логування обов'язкове з першого дня. Без логів причину збою в чужому діалозі відтворити майже неможливо.
Коротко
Розділення на шари, зовнішнє сховище станів, міграції бази й логи. Ці чотири речі відрізняють бот, який розвивають, від бота, який переписують.