Мой бот для парсинга каналов прислал пустой дайджест 😐
В логах — бан на 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 😁
Дискуссия