System Design Space
Граф знанийНастройки

Обновлено: 25 марта 2026 г. в 04:52

Web Crawler

medium

Классическая задача: distributed URL frontier, politeness/robots.txt, deduplication, re-crawl и ingestion в поисковый индекс.

Веб-краулер - это не задача про скачать весь интернет, а про frontier scheduling, politeness, deduplication и контроль того, что сканировать снова и когда.

Глава помогает разобрать URL frontier, распределение очередей, rate limits per domain, parsing pipeline и переход от сырых страниц к индексу.

В интервью и инженерных обсуждениях кейс полезен тем, что проверяет умение проектировать систему с бесконечным входным пространством и очень неоднородным внешним миром.

Pipeline Thinking

Критичны ingestion, partitioning, deduplication и задержки между стадиями обработки.

Serving Layer

Решения по индексам, cache locality и query path определяют пользовательскую latency.

Consistency Window

Явно фиксируйте, где допустима eventual consistency и где требуется stronger guarantees.

Cost vs Freshness

Балансируйте скорость обновления данных и стоимость вычислений/хранения.

Источник

System Design Interview

Web Crawler - один из базовых кейсов для обсуждения frontier, politeness и масштабирования.

Открыть обзор

Web Crawler решает две задачи одновременно: максимизировать coverage интернета и не перегружать чужие сервисы. Поэтому архитектура строится вокруг трёх идей: распределённый frontier, strict politeness по доменам и инкрементальное обновление контента.

Требования

Функциональные

Принять стартовый набор seed URL и регулярно расширять coverage.

Соблюдать robots.txt, crawl-delay и per-host rate limits.

Извлекать контент и ссылки, нормализовывать URL и убирать дубликаты.

Поддерживать re-crawl с разной частотой для hot и cold страниц.

Экспортировать данные в индексирующий pipeline (поисковый слой).

Нефункциональные

Scale: миллиарды URL

Frontier и storage должны масштабироваться горизонтально.

Freshness: минуты-часы

Популярные страницы должны быстро переобходиться.

Politeness: per-domain fairness

Нельзя перегружать один хост массовыми запросами.

Reliability: resume after failures

Очереди и checkpointing не должны терять crawl-прогресс.

High-Level Architecture

Web Crawler: High-Level Map

frontier + scheduling + fetch/parse/storage pipeline

Control Plane

Seed Sources -> URL Frontier -> Scheduler -> Policy Engine
prioritization + politeness
Crawl Event Log
fetch outcomes + retries

Data Plane

Web Sites -> Fetchers -> Parser
fetch + parse path
Dedup -> Content Store -> Indexing
storage + publication

Crawler разделён на control plane (frontier, policy, scheduling) и data plane (fetch, parse, storage, indexing).

Как и в других distributed кейсах, ключевой паттерн — явное разделение control plane и data plane. Это позволяет отдельно масштабировать логику scheduling/politeness и сам fetch pipeline.

Crawl Flow

Crawl Flow Explorer

Стиль read/write flow: переключай сценарий и проигрывай ключевые шаги.

1
URL Frontier
pick next candidate
2
Scheduler
budget + lease
3
Fetcher Pool
HTTP request/response
4
Parser + Dedup
links + canonicalization
5
Store + Indexing
persist + publish events
Fetch path: проиграйте сценарий, чтобы увидеть полный цикл от frontier до публикации в indexing.

Fetch Path: operational notes

  • Frontier выдает URL с учетом priority score и per-host fairness.
  • Scheduler применяет host budget и crawl-delay перед выдачей lease.
  • Fetcher запрашивает страницу, parser извлекает контент и ссылки.
  • После canonicalization новые URL возвращаются в frontier loop.
  • Документ и metadata публикуются в indexing pipeline.

Recrawl Path: operational notes

  • Freshness scorer выбирает URL для переобхода на основе stale-окна.
  • Для hot pages re-crawl идет чаще, для cold — реже и batch-режимом.
  • Conditional fetch (ETag/Last-Modified) снижает трафик и CPU.
  • Результат обхода пишется в crawl event log для retry/observability.
  • URL возвращается в frontier с обновленным next_fetch_at.

Data Model (упрощённо)

  • frontier_queue: url_hash, priority, next_fetch_at, host_key, depth
  • host_budget: host_key, tokens, refill_rate, crawl_delay_ms
  • seen_urls: url_hash, first_seen_at, last_fetch_status
  • page_store: page_id, url, content_pointer, fetched_at, checksum
  • crawl_events: fetch_started/fetch_succeeded/fetch_failed/retry_scheduled

Надёжность и anti-patterns

Production-паттерны

  • Idempotent fetch pipeline: повторная обработка URL не ломает состояние.
  • Checkpoint frontier и offset-ов очереди для restart без потерь.
  • Per-host circuit breaker для проблемных доменов.
  • Adaptive retry policy: exponential backoff + jitter по типу ошибок.
  • Шардирование frontier по host hash, чтобы снизить lock contention.

Ошибки, которые часто встречаются

  • Глобальный FIFO без per-host лимитов: быстро приводит к банам и блокировкам.
  • Отсутствие canonicalization URL (utm, trailing slash, case) -> взрыв дублей.
  • Переобход «всего одинаково» без importance/freshness scoring.
  • Хранение всего контента только в RAM-очередях без durable слоя.
  • Игнорирование robots.txt и legal/compliance ограничений.

RFC

Robots Exclusion Protocol

Официальная спецификация robots.txt и правил взаимодействия crawler с сайтами.

Открыть RFC

Ключевой trade-off: максимальный throughput vs politeness/legal compliance. На интервью важно показать, как вы ограничиваете скорость по доменам и сохраняете устойчивость при отказах.

Связанные главы

  • Search System - показывает, как crawler-пайплайн питает индекс, query processing и ranking контур.
  • Distributed File System - дополняет durable storage-слой для crawl artifacts, snapshots и recovery после сбоев.
  • Rate Limiter - углубляет politeness-политику: per-host ограничения, backoff и защиту от перегрузки источников.
  • CDN - помогает понять edge-контекст и поведение трафика, которое влияет на стратегию обхода и freshness.

Чтобы отмечать прохождение, включи трекинг в Настройки