Мой бот для парсинга каналов прислал пустой дайджест 😐
В логах — бан на 7 часов за слишком частые запросы. Классический FloodWait как повод разобраться в теме.
Даже скорее освежить тему rate limiting и понять, откуда это взялось.
Еще в 90-х один агрессивный клиент мог положить сервис для всех.
Поэтому начали считать запросы: превысил порог — получи отказ. С ростом API-экономики это стало стандартом. Сегодня нет ни одного серьезного API без rate limiting.
Устроено так, что каждый сервис реализует это по-своему. Telegram отправляет FloodWait с указанием количества секунд ожидания. OpenAI и большинство REST API возвращают ошибку HTTP 429 Too Many Requests.
Google считает квоты посуточно. Некоторые сервисы просто без предупреждения замедляют ответы.
Три основных алгоритма:
— фиксированное окно (N запросов в минуту)
— скользящее окно
— token bucket
Для компаний это, очевидно, защита инфраструктуры, а заодно и инструмент монетизации🤌: бесплатный тариф — 10 запросов в минуту, платный — 1000.
Плюс защита от злоупотреблений: парсинга, спама, накруток.
Стоит учесть несколько практических рекомендаций ✍️
➔ Надо изучать лимиты до написания кода, а не после бана
➔ Тестировать на реальном объеме — 15 и 300 запросов это разные вселенные
➔ Ставить паузы между запросами (3–5–8 секунд, если лимиты не указаны)
➔ Обрабатывать 429/FloodWait
➔ Кэшировать ответы — не запрашивайте одно и то же
➔ Логировать отказы — без логов причину не найдете
Мой случай оказался учебным: бот нормально работал на тесте и упал на проде.
Добавил паузы и обработку ошибок — все заработало 🌟
Но 7 часов простоя можно было избежать, если бы я просто дочитал документацию Telegram 😁