Делюсь наблюдениями. Сбор цен/остатков с маркетплейсов (озвучу абстрактно, без названий) на объёмах стабильно упирается в капчи и поведенческие фильтры. Лёгкие прокси и паузы уже не спасают, а нестабильность бьёт по отчётам и автоматике ценообразования.
Что у меня сработало частично: разнесение расписаний по «окнам низкой турбулентности», ротация User-Agent’ов по семействам устройств, прогрев сессий через «серые» страницы, агрессивный кеш валидных ответов и дедупликация запросов на уровне ключей SKU. Но всё равно периодические баны и внезапные редиректы на капчу ломают пайплайн и тревожат SLA.
Интересует практика комьюнити по трем пунктам: 1) как вы распознаёте начало жёсткого rate limiting до того, как полетит половина запросов; 2) как автоматизируете «план Б» (переключение на API-поставщиков/бэкап-источники) без ручного вмешательства; 3) чем заменяете headless-браузеры, когда CPU/память съедают экономику задачи. Понимаю риски и правила площадок, речь про техническую сторону и минимизацию лишних ударов по инфраструктуре. С радостью посмотрю на архитектурные схемы, подходы к очередям/ретраям и метрики для алертов, чтобы не ловить сюрпризы в пике продаж)