System Design Space

    Глава 27

    Обновлено: 16 февраля 2026 г. в 03:00

    Web Crawler

    Прогресс части0/21

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

    Источник

    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 ограничений.

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

    Search SystemDistributed File SystemRate LimiterCDN

    RFC

    Robots Exclusion Protocol

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

    Открыть RFC

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