Как не сжечь сервер и бюджет на анти-капчу при массовом скрапинге

Как не сжечь сервер и бюджет на анти-капчу при массовом скрапинге

Высоконагруженный парсинг ломается не на логике, а на физике: CPU, RAM, сеть и лимиты анти-бота. Сначала режь лишнее — не качай HTML, если хватает JSON, не тащи тяжёлые ассеты, не прогоняй весь DOM через селекторы без фильтра.

Дальше смотри на стоимость одного запроса:
— прокси дешевле масштабировать, чем бесконечно ретраить один и тот же IP;
— пул воркеров должен быть меньше, чем очередь задач, иначе получишь thrashing и рост latency;
— капча — это не «ошибка», а отдельный класс нагрузки, который надо считать в пайплайне.

Анти-капчу выгодно включать только после триггера: рост 403/429, резкие редиректы, пустые ответы с нормальным TTFB. До этого лучше держать adaptive backoff, ротацию fingerprints и кэш уже решённых challenge-токенов. Если токен живёт дольше одного обхода, не сливай его в мусорную корзину.

На сервере экономия делается не героизмом, а архитектурой: батчинг запросов, дедуп по URL, ограничение параллелизма на домен, агрессивный timeout и ранний abort на мусорных страницах. Профит оправдывает средства, но только если у тебя есть метрика «стоимость успешного документа», а не просто счёт за железо.

Сначала считай throughput и hit rate, потом докручивай анти-капчу и железо; иначе масштабируешь не систему, а убыток.