Три інтервали затримки для трьох API

У квітні я побудував ETL-конвеєри для трьох сайтів-каталогів. Кожен сайт використовує інший API: Steam, GitHub та HuggingFace.

Мені довелося встановити інтервали затримки для кожного з них. Числа, сценарії збоїв та обробка помилок — усе різне. Ось що я використовую і чому.

Steam: затримка 250 мс

Документація Steam нечітко описує ліміти запитів (rate limits). Дані спільноти вказують приблизно на 200 запитів кожні 5 хвилин на одну IP-адресу. Це означає, що інтервал у 1,5 секунди буде безпечним.

Замість цього я використовую 250 мс. Моє нічне завдання обробляє лише 60 записів ігор. При затримці 250 мс загальний час очікування становить 15 секунд. При 1,5 секундах він зростає до 90 секунд. Економія часу має значення, коли ви обробляєте кілька сайтів.

Якщо Steam повертає помилку, завдання не зупиняється. Воно реєструє помилку в логах і переходить до наступного елемента. Дані оновлюються наступної ночі.

GitHub: затримка 100 мс

GitHub дуже чіткий. Неавтентифіковані користувачі отримують 60 запитів на годину. Користувачі з токеном отримують 5 000 запитів на годину.

Я використовую затримку 100 мс як міру ввічливості. Токен бере на себе основне навантаження щодо лімітів. Мій конвеєр використовує основний REST API, а не search API. Це дозволяє мати набагато вищі ліміти.

HuggingFace: без затримки

За тижні нічних запусків я жодного разу не вперся в ліміт запитів. Registry API розроблений саме для інструментів пакетної обробки, подібних до мого.

Я завантажую до 100 моделей за один раз. Я використовую токен автентифікації, щоб ще більше підвищити ліміти. Для 100 моделей відсутність затримки — найпростіше рішення.

Підсумкова таблиця:

• Steam: затримка 250 мс. Некритичні помилки. • GitHub: затримка 100 мс. Некритичні помилки. • HuggingFace: без затримки. Некритичні помилки.

Інтервал затримки — це лише припущення. Справжній захист полягає в тому, як я обробляю помилки. Кожен виклик API використовує блок try/catch. Якщо виклик не вдається, система записує резервний рядок (fallback row) замість того, щоб аварійно завершити роботу.

Інтервал затримки контролює, як часто ви досягаєте ліміту. Обробка помилок контролює те, що відбувається, коли ви його досягаєте.

Джерело: https://dev.to/morinaga/three-sleep-intervals-for-three-apis-steam-250ms-github-100ms-huggingface-none-4ga7

Додаткова спільнота для навчання: https://t.me/GyaanSetuAi