Архитектура ТГ софта для инвайтинга № 12474

Мы разрабатываем свой веб-сервис для приглашения пользователей в ТГ-чаты: FastAPI + Telethon, SQLite, Docker. Сейчас в нём есть: -база аккаунтов; -парсинг аудитории; -кампании инвайта с паузами и лимитами; -проверка, появился ли приглашённый в чате. Проблема: часть аккаунтов получает PEER_FLOOD или «тихие» отказы. ТГ принимает запрос, но человек в чате не появляется. Стабильно работает только один, самый старый аккаунт. Ищем практика, у которого есть своя рабочая система инвайтинга и который разбирается, как ТГ оценивает аккаунты. Что нужно: Разобрать нашу логику работы с аккаунтами: очереди, лимиты, паузы, обработку ошибок (PEER_FLOOD, приватность, missing_invitees, нет прав админа, слетевшие сессии). Рассказать, как устроена ваша система: -как вы определяете «здоровье» аккаунта; -когда выводите аккаунт из работы и когда возвращаете; -какие лимиты считаете безопасными. Проконсультировать, как правильно ввести новые аккаунты в работу, чтобы они вели себя как обычные пользователи, а не как сеть и где покупать прогретые аккаунты. Дать список конкретных доработок по приоритету. Формат: созвон на 1–2 часа и письменные рекомендации после него. Код писать не нужно, дорабатываем сами. Требования: свой опыт инвайтинга и работы с пулом аккаунтов, желательно знание Telethon или Pyrogram. В отклике коротко опишите свой опыт и систему.