При общей очереди один активный бот может задержать апдейты остальных интеграций. Планируете ли вы fair scheduling по integration_id, отдельные concurrency limits и сохранение порядка внутри одного chat_id после распараллеливания воркеров? Для платежных событий также важно различать повторную доставку апдейта и повтор после частично выполненного side effect.
Не совсем понял один момент в платёжном примере. В статье правильно сказано, что сумму лучше хранить в минимальных единицах токена, но в usdt_payment_check.py она преобразуется в float, а порог задан как 10.0 * 0.99. При обычном ERC‑20-переводе сетевая комиссия оплачивается отдельно в нативной валюте и не вычитается из значения Transfer. Если учитывается комиссия биржи при выводе или fee-on-transfer, это уже отдельное правило для конкретного источника или контракта, а не универсальный допуск в 1%. Для сервисов автоматической выдачи доступа вроде Tribute или Nemiling такой допуск фактически становится бизнес-правилом: от него зависит, будет ли активирована подписка после неполной оплаты. Поэтому я бы оставил сумму целым числом и сверял её с expected_units конкретного заказа.
И подскажите, допуск в 1% появился из реальных случаев вывода с бирж или это страховка от погрешности float?
Здесь, кажется, стоит разделить две проблемы. Ошибка в расчёте видна из самого SQL: base уже содержит строку на каждое сообщение, а второй JOIN messages повторно присоединяет все сообщения пользователя без привязки к конкретному персонажу. В результате строки размножаются и метрика искажается.
А вот гарантированный subquery unnesting failure и последующий Lock Wait Timeout из текста запроса уже не следуют. MySQL 8 может преобразовать такой IN в semijoin, поэтому без EXPLAIN и информации об индексах нельзя уверенно сказать, какой план был выбран и где именно возникло узкое место.
Сохранился ли план выполнения исходного запроса? Было б интересно сравнить его с исправленной версией.
Классный вывод тут, кажется, не про сам HTTP 200, а про отдельный unknown. Я бы ещё сохранял не только статус, но и причину: rate_limited, empty_page, parse_error, ambiguous_type. И не разрешал бы результату, полученному только из HTML, запускать необратимое действие без повторной проверки. Для многих сервисов, где подключённые Telegram-каналы и группы завязаны на оплату и управление доступом, ложный not found — это уже не просто ошибка в статистике: можно отклонить вполне существующее сообщество. Поэтому полезно хранить ещё и источник вывода — по какому признаку он сделан и когда получен.
Кстати, пустую страницу при ограничении частоты не пробовали определять по стабильному шаблону или хешу ответа? Это хотя бы позволило бы отличать throttling от обычного «не удалось классифицировать».
Интересная аналитика, спасибо. Но MAU, кажется, не всегда подходит для сравнения обычных ботов и B2B-сервисов.
Иногда один активный администратор может управлять целым платным сообществом. Поэтому MAU основного бота не показывает реальный масштаб. Здесь полезнее смотреть на количество активных проектов, плательщиков и GMV.
Не думали выделить такие сервисы в отдельную категорию?
Для MVP — хороший пример. Но в текущем варианте pre_checkout_query всегда подтверждается через ok=True, а количество запросов определяется из invoice_payload.
В проде, возможно, стоит сверять данные платежа с записью о заказе в БД: пользователя, валюту и сумму. telegram_payment_charge_id также стоит хранить как уникальный — иначе при повторной обработке одного и того же update баланс пользователя может увеличиться дважды.
С платными подписками многие проходили похожий путь: принять платеж оказывалось самой простой частью. Дальше начинались возвраты, продления, сверка платежей и автоматическая выдача или отзыв доступа.
Было бы интересно увидеть продолжение про идемпотентность, refundStarPayment и обработку жизненного цикла подписки. Планируете развивать пример в эту сторону?
Свой бот даёт полный контроль, но вместе с этим есть и множество издержек: появляется поддержка платежей, управление доступом, продления, блокировки и постоянное сопровождение. Если собственная разработка не является частью продукта, можно сравнить её стоимость с готовой платформой, особенно если тарифы фиксированные и по низким ценам. Вообще их много разных, но недавно стал пользовался Nemiling. В целом, нареканий нет. Но понятно, что на вкус и цвет…
За последние пару лет ТГ вообще сильно изменился. Превратился не просто в месенджер, а платформу для цифровых сервисов. Каждый день кто-то пилит Mini Apps, кто-то продаёт подписки на каналы, группы и тд. Посмотрим, куда Telegram придет в дальнейшем.
Именно поэтому и не пошёл в сторону Zabbix. Pi 4 с 2GB весь бы уходил на мониторинг. Prometheus с node_exporter на Pi держит около 200-300MB суммарно, что вполне комфортно вроде бы
HA смотрел, но для чистого мониторинга серверов это как из пушки по воробьям. Там экосистема заточена под умный дом, мне же нужны были просто метрики CPU, памяти и дисков с алертами. Prometheus + node_exporter для этого проще и легче на мой взгляд, но возможно заблуждаюсь.
Managed Bots это интересно, но а как на практике будет себя вести с точки зрения стабильности? Особенно в сценариях где один бот падает посередине цепочки. Кто отвечает за retry логику, каждый бот сам или управляющий?
Недавно пробовал строить что-то похожее вручную через webhook цепочки. Основная боль была именно в обработке частичных сбоев. Как вы справляетесь?
Про имена ботов - это реально работает, не просто забава. Сам недавно назвал одного именем и заметил что стал внимательнее писать обработку ошибок. Когда у системы есть имя, почему-то подсознательно меняется отношение к тому что с ней может пойти не так.
Общаются ли у вас боты между собой напрямую через Telegram API или через внутреннюю очередь? Если точнее, как настроили синхронизацию когда несколько ботов должны обработать одну заявку.
По 173-ФЗ важен не бренд, а кто платит. В Tribute вам платит иностранное юрлицо (TRBT Limited), а это уже лишние вопросы по валютке и агентской схеме.
Есть Российский аналог - Nemiling. Там подписчики платят напрямую, без иностранного посредника. Это обычная оплата от физлиц за контент, а не платежи из-за границы.
Nemiling, конечно, не волшебная таблетка, но схема проще и для работы в РФ понятнее.
Про pre_checkout_query всё правильно написано, это реально камень преткновения для всех кто первый раз делает платежи в боте. Сам на нём потерял пару часов.
Добавлю один момент который в статье не упомянут: если переходить на Stars вместо классических провайдеров, currency меняется на XTR и provider_token не нужен вообще. Но появляется новая проблема с возвратами: Telegram может сделать refund по запросу пользователя и нужно обрабатывать refunded_payment иначе доступ у человека останется хотя деньги уже вернулись.
Я бы сперва не в журнал, а показал бы статью математикам с профильной кафедры или в институте. Если скажут, что тема реально новая, а они по любому в курсе, они же и журнал нормальный подскажут, и с оформлением могут помочь. Сейчас частные авторы тоже спокойно публикуются, главное, чтобы сама работа была сильной
Статья огонь, спасибо за разбор по адресам. Знакомый попал на похожую схему, только называлась Nuwonex. Я его отговаривал, показывал примеры других пирамид, объяснял как работает эта механика. Не послушал.
Классика: закинул 5000, через неделю вывел 10000. После этого похоже мозг отключился, а в глазах загорелись доллары. Он вкинул 50000 и решил подождать пока на счёте не нарисуется 100000. Как только цифра появилась, аккаунт заблокировали. Якобы пользователям из РФ закрыли доступ, поддержка молчит, деньги исчезли. Говорил что собирался вывести и не успел буквально на минутку.
Первый вывод это самое хитрое место. Человек получает реальные деньги, мозг фиксирует что схема работает, и дальше уже несёт в разы больше не задумываясь. После того как это случилось, он зарекался больше не верить в подобные схемы. А через месяц пришёл ко мне с новой темкой, мол есть вариантик в крипте приумножиться)))
Похоже такое даже горьким опытом не лечится, к сожалению.
Это очень точно. Я примерно к тому же пришёл когда пробовал вайбкодинг на своём pet-проекте. Первые два дня шли быстро потому что задача была маленькая и хорошо у меня в голове структурирована. Как только начались пограничные случаи модель стала предлагать решения которые противоречили тому что уже написано. И я понял что проблема была не в модели, а в том что я сам не мог чётко объяснить как части системы должны взаимодействовать. Особенно учитывая что каждый раз приходилось править по структуре из головы.
Plan mode это интересно. Не пробовал, буду смотреть.
При общей очереди один активный бот может задержать апдейты остальных интеграций. Планируете ли вы fair scheduling по
integration_id, отдельные concurrency limits и сохранение порядка внутри одногоchat_idпосле распараллеливания воркеров? Для платежных событий также важно различать повторную доставку апдейта и повтор после частично выполненного side effect.Не совсем понял один момент в платёжном примере. В статье правильно сказано, что сумму лучше хранить в минимальных единицах токена, но в
usdt_payment_check.pyона преобразуется вfloat, а порог задан как10.0 * 0.99.При обычном ERC‑20-переводе сетевая комиссия оплачивается отдельно в нативной валюте и не вычитается из значения
Transfer. Если учитывается комиссия биржи при выводе илиfee-on-transfer, это уже отдельное правило для конкретного источника или контракта, а не универсальный допуск в 1%.Для сервисов автоматической выдачи доступа вроде Tribute или Nemiling такой допуск фактически становится бизнес-правилом: от него зависит, будет ли активирована подписка после неполной оплаты. Поэтому я бы оставил сумму целым числом и сверял её с
expected_unitsконкретного заказа.И подскажите, допуск в 1% появился из реальных случаев вывода с бирж или это страховка от погрешности
float?Здесь, кажется, стоит разделить две проблемы. Ошибка в расчёте видна из самого SQL:
baseуже содержит строку на каждое сообщение, а второйJOIN messagesповторно присоединяет все сообщения пользователя без привязки к конкретному персонажу. В результате строки размножаются и метрика искажается.А вот гарантированный
subquery unnesting failureи последующийLock Wait Timeoutиз текста запроса уже не следуют. MySQL 8 может преобразовать такойINв semijoin, поэтому безEXPLAINи информации об индексах нельзя уверенно сказать, какой план был выбран и где именно возникло узкое место.Сохранился ли план выполнения исходного запроса? Было б интересно сравнить его с исправленной версией.
Классный вывод тут, кажется, не про сам HTTP 200, а про отдельный
unknown. Я бы ещё сохранял не только статус, но и причину:rate_limited,empty_page,parse_error,ambiguous_type. И не разрешал бы результату, полученному только из HTML, запускать необратимое действие без повторной проверки. Для многих сервисов, где подключённые Telegram-каналы и группы завязаны на оплату и управление доступом, ложныйnot found— это уже не просто ошибка в статистике: можно отклонить вполне существующее сообщество. Поэтому полезно хранить ещё и источник вывода — по какому признаку он сделан и когда получен.Кстати, пустую страницу при ограничении частоты не пробовали определять по стабильному шаблону или хешу ответа? Это хотя бы позволило бы отличать throttling от обычного «не удалось классифицировать».
Интересная аналитика, спасибо. Но MAU, кажется, не всегда подходит для сравнения обычных ботов и B2B-сервисов.
Иногда один активный администратор может управлять целым платным сообществом. Поэтому MAU основного бота не показывает реальный масштаб. Здесь полезнее смотреть на количество активных проектов, плательщиков и GMV.
Не думали выделить такие сервисы в отдельную категорию?
Для MVP — хороший пример. Но в текущем варианте
pre_checkout_queryвсегда подтверждается черезok=True, а количество запросов определяется изinvoice_payload.В проде, возможно, стоит сверять данные платежа с записью о заказе в БД: пользователя, валюту и сумму.
telegram_payment_charge_idтакже стоит хранить как уникальный — иначе при повторной обработке одного и того жеupdateбаланс пользователя может увеличиться дважды.С платными подписками многие проходили похожий путь: принять платеж оказывалось самой простой частью. Дальше начинались возвраты, продления, сверка платежей и автоматическая выдача или отзыв доступа.
Было бы интересно увидеть продолжение про идемпотентность,
refundStarPaymentи обработку жизненного цикла подписки. Планируете развивать пример в эту сторону?Свой бот даёт полный контроль, но вместе с этим есть и множество издержек: появляется поддержка платежей, управление доступом, продления, блокировки и постоянное сопровождение.
Если собственная разработка не является частью продукта, можно сравнить её стоимость с готовой платформой, особенно если тарифы фиксированные и по низким ценам. Вообще их много разных, но недавно стал пользовался Nemiling. В целом, нареканий нет.
Но понятно, что на вкус и цвет…
За последние пару лет ТГ вообще сильно изменился. Превратился не просто в месенджер, а платформу для цифровых сервисов.
Каждый день кто-то пилит Mini Apps, кто-то продаёт подписки на каналы, группы и тд.
Посмотрим, куда Telegram придет в дальнейшем.
Не слышал про такую связку, спасибо. Посмотрю. У вас на Pi крутится или на отдельной машине?
Именно поэтому и не пошёл в сторону Zabbix. Pi 4 с 2GB весь бы уходил на мониторинг. Prometheus с node_exporter на Pi держит около 200-300MB суммарно, что вполне комфортно вроде бы
HA смотрел, но для чистого мониторинга серверов это как из пушки по воробьям. Там экосистема заточена под умный дом, мне же нужны были просто метрики CPU, памяти и дисков с алертами. Prometheus + node_exporter для этого проще и легче на мой взгляд, но возможно заблуждаюсь.
Managed Bots это интересно, но а как на практике будет себя вести с точки зрения стабильности? Особенно в сценариях где один бот падает посередине цепочки. Кто отвечает за retry логику, каждый бот сам или управляющий?
Недавно пробовал строить что-то похожее вручную через webhook цепочки. Основная боль была именно в обработке частичных сбоев. Как вы справляетесь?
Про имена ботов - это реально работает, не просто забава. Сам недавно назвал одного именем и заметил что стал внимательнее писать обработку ошибок. Когда у системы есть имя, почему-то подсознательно меняется отношение к тому что с ней может пойти не так.
Общаются ли у вас боты между собой напрямую через Telegram API или через внутреннюю очередь? Если точнее, как настроили синхронизацию когда несколько ботов должны обработать одну заявку.
По 173-ФЗ важен не бренд, а кто платит. В Tribute вам платит иностранное юрлицо (TRBT Limited), а это уже лишние вопросы по валютке и агентской схеме.
Есть Российский аналог - Nemiling. Там подписчики платят напрямую, без иностранного посредника. Это обычная оплата от физлиц за контент, а не платежи из-за границы.
Nemiling, конечно, не волшебная таблетка, но схема проще и для работы в РФ понятнее.
Про pre_checkout_query всё правильно написано, это реально камень преткновения для всех кто первый раз делает платежи в боте. Сам на нём потерял пару часов.
Добавлю один момент который в статье не упомянут: если переходить на Stars вместо классических провайдеров, currency меняется на XTR и provider_token не нужен вообще. Но появляется новая проблема с возвратами: Telegram может сделать refund по запросу пользователя и нужно обрабатывать refunded_payment иначе доступ у человека останется хотя деньги уже вернулись.
Я бы сперва не в журнал, а показал бы статью математикам с профильной кафедры или в институте. Если скажут, что тема реально новая, а они по любому в курсе, они же и журнал нормальный подскажут, и с оформлением могут помочь. Сейчас частные авторы тоже спокойно публикуются, главное, чтобы сама работа была сильной
Принято) Буду расширять свои познания!
Статья огонь, спасибо за разбор по адресам. Знакомый попал на похожую схему, только называлась Nuwonex. Я его отговаривал, показывал примеры других пирамид, объяснял как работает эта механика. Не послушал.
Классика: закинул 5000, через неделю вывел 10000. После этого похоже мозг отключился, а в глазах загорелись доллары. Он вкинул 50000 и решил подождать пока на счёте не нарисуется 100000. Как только цифра появилась, аккаунт заблокировали. Якобы пользователям из РФ закрыли доступ, поддержка молчит, деньги исчезли. Говорил что собирался вывести и не успел буквально на минутку.
Первый вывод это самое хитрое место. Человек получает реальные деньги, мозг фиксирует что схема работает, и дальше уже несёт в разы больше не задумываясь. После того как это случилось, он зарекался больше не верить в подобные схемы. А через месяц пришёл ко мне с новой темкой, мол есть вариантик в крипте приумножиться)))
Похоже такое даже горьким опытом не лечится, к сожалению.
Это очень точно. Я примерно к тому же пришёл когда пробовал вайбкодинг на своём pet-проекте. Первые два дня шли быстро потому что задача была маленькая и хорошо у меня в голове структурирована. Как только начались пограничные случаи модель стала предлагать решения которые противоречили тому что уже написано. И я понял что проблема была не в модели, а в том что я сам не мог чётко объяснить как части системы должны взаимодействовать. Особенно учитывая что каждый раз приходилось править по структуре из головы.
Plan mode это интересно. Не пробовал, буду смотреть.
Как то я упустил это! Изучим, спасибо)