System Design Cases
[SYSTEM DESIGN] Search Engine
Web-scale search engine (Google-like). Crawler -> URL frontier (Kafka) -> fetcher -> parser -> bulk indexer -> sharded inverted Lucene index (150 shards × RF 3). Query path: API gateway -> query cache -> spell corrector -> query rewriter -> coordinator (scatter-gather) -> shards (BM25) -> PageRank static scores -> ML re-ranker (LambdaMART). Auto-suggest service backed by in-RAM prefix trie. Semantic search via embedding model + HNSW vector index, fused with BM25 via Reciprocal Rank Fusion. Five scenarios: crawl-and-index a new page, search query (BM25 + ML rerank), auto-suggest while typing, spell correction "googel" -> "google", hybrid vector + lexical retrieval. Two ADRs: inverted index sharding strategy (document-partitioning vs term-partitioning), BM25 vs vector vs hybrid retrieval.
Распределённая поисковая система
Схема соединяет polite web crawl, канонизацию документов, lexical shards, ANN retrieval, fusion и bounded reranking. Это учебная архитектура с явными допущениями; конкретные QPS и latency требуют измерения на выбранном корпусе, анализаторах, фильтрах и оборудовании.
Ёмкость индекса
Допустим, первичный lexical index занимает 15 ТБ. При 300 primary shards это около 50 ГБ primary data на shard. Replication factor 3 даёт примерно 45 ТБ сырых копий до translog, segment merge headroom, snapshots и filesystem overhead.
Документ по routing key попадает ровно в одну primary replication group. Primary валидирует запись и реплицирует её in-sync copies. Поэтому анимация трёх ветвей Index Router показывает разные документы одного bulk, а не запись одного документа «во все шарды».
Для вектора 768 × float32 сырой нижний предел равен 3 072 байта на документ. HNSW links, ids, metadata, deleted entries и allocator добавляют существенный overhead, поэтому 3 КБ нельзя использовать как полный размер ANN index.
Crawl frontier
URL Frontier разделён по host и next-fetch time. Fetcher сам получает eligible work из frontier, проверяет robots.txt policy, redirect/size/content-type limits и lease в URL Seen Store. Parser:
- нормализует URL осторожно, не смешивая семантически разные страницы;
- учитывает declared canonical как сигнал, а не слепую истину;
- сохраняет content fingerprint и version;
- возвращает новые разрешённые ссылки в host-keyed frontier.
Robots Exclusion Protocol стандартизован RFC 9309. robots.txt — не механизм авторизации: закрытые данные всё равно требуют доступа на origin.
Индексация и видимость
Canonical Document Store позволяет переиндексировать без повторного скачивания. Index Router группирует bulk по routing key. Lexical search near-real-time: успешная индексация не обязана означать мгновенную видимость в search до refresh. Vector visibility имеет собственный lag; версии lexical и vector index попадают в ответ и cache key.
CDC уместен для product/catalog search, где источник — транзакционная БД. В показанном web-search pipeline источником является crawler, поэтому CDC не выдается за обязательный компонент схемы.
Query serving
Coordinator выбирает одну активную копию каждого relevant shard, рассылает запрос, собирает local top-K и выполняет bounded merge. Query Cache key включает:
- нормализованный query;
- locale, filters, safe-search и ACL scope;
- index version, synonym version и ranking model version.
Персонализированный или ACL-зависимый результат нельзя разделять между пользователями без безопасного scope. Кэш заполняется только после успешного ответа и получает короткий bounded TTL.
Spell Service рассматривает googel → google как перестановку соседних символов. Исправление применяется только при достаточной уверенности и показывается пользователю.
Hybrid retrieval
Lexical BM25 и ANN дают два ранжированных списка. Reciprocal Rank Fusion объединяет позиции без предположения, что raw scores сопоставимы. ML reranker получает только ограниченный top set. При недоступности ANN или reranker система деградирует к fused/lexical результату, а не блокирует весь поиск.
Статический PageRank-подобный link-quality signal — лишь один versioned feature; финальный ranking также учитывает текст, freshness, spam/safety и продуктовые правила.
Timeout и partial results
Elasticsearch-подобный search может вернуть HTTP success с partial shard results и метаданными timed_out/_shards. Продукт обязан показать partial=true и failed-shard metadata. Если отсутствующий shard содержит обязательные ACL, legal или safety данные, система fail closed и не возвращает потенциально запрещённый результат.
Сценарии
Polite crawl, canonical dedupe, один primary group на документ и отдельная vector indexing path.
Cache miss, rewrite, lexical scatter/gather, bounded reranking и безопасное заполнение cache.
Отдельный low-latency prefix path.
Transposition-aware correction без скрытой принудительной подмены.
ANN + lexical fusion, RRF и graceful degradation.
Явный partial result для общего поиска и fail-closed policy для обязательных данных.
Наблюдаемость
- frontier age, fetch success by host/status, robots cache age и duplicate ratio;
- indexing lag отдельно для lexical и vector;
- shard fan-out, rejected requests, cache hit/miss QPS и cache-key cardinality;
- p50/p95/p99 по cache hit, lexical, ANN, fusion и reranking;
- partial-result rate, failed shard ids и доля fail-closed policy decisions;
- relevance metrics по model/index version.
Связанные материалы
[CONCEPT]elasticsearch [CONCEPT]sharding-strategies [CONCEPT]replication [CONCEPT]caching-patterns [CONCEPT]change-data-capture [CONCEPT]observability-pillars [CASE]recommendation-systemПервичные источники
- Elasticsearch reading and writing documents: https://www.elastic.co/docs/deploy-manage/distributed-architecture/reading-and-writing-documents
- Elasticsearch clusters, nodes and shards: https://www.elastic.co/docs/deploy-manage/distributed-architecture/clusters-nodes-shards
- Elasticsearch near real-time search: https://www.elastic.co/docs/manage-data/data-store/near-real-time-search
- RFC 9309 Robots Exclusion Protocol: https://www.rfc-editor.org/rfc/rfc9309.html
- Reciprocal Rank Fusion paper: https://research.google/pubs/reciprocal-rank-fusion-outperforms-condorcet-and-individual-rank-learning-methods/
- Lucene BM25Similarity: https://lucene.apache.org/core/7_6_0/core/org/apache/lucene/search/similarities/BM25Similarity.html