Задача: Доработка Telegram-бота (Чекер) и постоянная поддержка

Требуется доработать существующего Telegram-бота (на стеке Python 3.12 + Poetry, aiogram 3, FastAPI, Tortoise ORM, SQLite, Redis) для устранения логической дыры в обработке инвойсов. Сейчас бот работает на ручном подтверждении (поллинг), из-за чего пользователи могут повторно получить начисление, нажимая кнопки после завершения платежа.

Что нужно изменить

• Сменить механизм подтверждения: вместо поллинга (опрос БД) использовать вебхуки, приходящие от платёжной системы без доработок самого шлюза;
• Учесть в логике двойную проверку данных через клиент FastAPI в связке с БД (не только данные инвойса, но и текущая скорость машины пользователя, чтобы игнорировать запоздалые или повторные запросы), по сути хранить не только ID платежа, но и контекст состояния холста;
• Внедрить state-менеджмент через Redis: исключить возможность “моментального траншей” из-за очистки КЭШа. Система временных меток и готовых чекстов должна быть единой для бота и API;
• Написать защиту на логику: добавлять или править промежуточный коллбэк (Guard), блокирующий запрос, если в ID инвойса появился дубликат или в момент подтверждения юзер уже выполняет цикл (мутекса для БД достаточно на данном объёме);
• Глубокий рефакторинг одной (сломанной) функции process_success: сделать вызов шлюза/ручки с инвойсом атомарным, при ошибке откат до бека от Redis;
• Добавочно - проверить версии зависимостей aiogram 3.24, тутортоис ORM 0.24, утилизацию памяти от AioRedis

Общие требования

• Стек разработки: Python 3.12 (через Poetry), aiogram 3, FastAPI;
• Игноризировать любые вычитки интерфейсного слоя (ветка продекетирована под админкой на QT), с Vue 3 не работаем, поддержка в статичном моменте разве что через приновленные интерактивные событияи
• Коммуникация через Telegram, git-hook для нашей команды; обратня свявь в режиме daily таска 1-2 сообщения в TG;
• График работ: плотность времени - около двух рабочих недель, после созыва на проверку внедренияя.

Работа разовая (check box architecture с фазой аудита) + неделя техподдержки после внедрения могущей быть продлением в текущем ТЗ