Design a Web Crawler System Design Interview w/ a Ex-Meta Staff Engineer

Ось структурований конспект відео українською мовою.

1. Назва відео

Системний дизайн: Веб-краулер (Web Crawler)

2. Ключова тема

Системний дизайн

3. Мета відео

Розібрати, як спроєктувати масштабований відмовостійкий веб-краулер, який може зібрати 10 мільярдів веб-сторінок за 5 днів для навчання великої мовної моделі (LLM). У відео пояснюється, як пройти співбесіду з системного дизайну, використовуючи покрокову методологію та демонструючи глибину знань, очікувану для різних рівнів інженерів (від mid-level до staff).

4. Основні концепції та кроки

• Етапи співбесіди (Roadmap): Спікер пропонує чіткий план: 1) Визначення функціональних та нефункціональних вимог. 2) Документування основних сутностей (Core Entities) — текстові дані, метадані URL, метадані доменів. 3) Визначення інтерфейсу (Input/Output). 4) Опис потоку даних (Data Flow): від seed URL до збереження тексту. 5) High-Level Design — проста діаграма, що задовольняє лише функціональні вимоги. 6) Deep Dives — покрокове покращення дизайну для задоволення нефункціональних вимог.
• Проєктування на основі нефункціональних вимог: Замість того, щоб одразу рахувати "back-of-the-envelope", спікер радить робити розрахунки лише тоді, коли вони безпосередньо впливають на архітектурне рішення (наприклад, скільки машин-краулерів потрібно). Основні нефункціональні вимоги: відмовостійкість (fault tolerance), ввічливість (politeness), масштабованість (scalability) до 10 млрд сторінок, ефективність (efficiency) — встигнути за 5 днів.
• Розділення на етапи (Stage Separation) для відмовостійкості: Ключове рішення — розділити роботу краулера на два окремі етапи:
  1. Fetch: Завантаження сирого HTML з Інтернету та збереження у blob-сховище (S3). Це найскладніша та найпомилковіша частина.
  2. Parse: Читання HTML зі S3, вилучення тексту (збереження в S3) та посилань (URL), які додаються назад у чергу. Цей підхід дозволяє не перезавантажувати веб-сторінки при збоях або зміні вимог ML-команди.
• Повторні спроби (Retry Strategy) та Dead Letter Queue: Для обробки помилок завантаження сторінок пропонується використовувати Amazon SQS, який підтримує конфігуроване експоненційне уповільнення (exponential backoff). Після 5 невдалих спроб повідомлення автоматично переміщується в Dead Letter Queue, що дозволяє не витрачати ресурси на "мертві" URL.
• Ввічливість (Politeness) та robots.txt: Для дотримання правил кожного домену краулер повинен:
  1. При першому зверненні до домену завантажувати файл robots.txt і зберігати правила (disallowed paths, crawl-delay) у таблиці доменів.
  2. Перед завантаженням сторінки перевіряти, чи не заборонений шлях, і чи минув необхідний crawl-delay.
  3. Використовувати Redis для рейт-лімітингу (не більше 1 запиту на секунду на домен за замовчуванням) та додавати jitter (випадкову затримку), щоб уникнути "шторму" повторних запитів на один домен.
• Масштабування та планування потужності: Щоб завантажити 10 млрд сторінок за 5 днів, спікер робить приблизний розрахунок: з урахуванням обмежень (DNS, рейт-ліміти, помилки) один суперпотужний інстанс AWS зможе обробляти ~10 000 сторінок/сек (лише ~30% від теоретичної пропускної здатності). Це дає ~10 днів на один інстанс, тому для 5 днів потрібно ~2 машини, але з запасом — 4 машини-краулери.
• Оптимізація DNS: DNS може стати вузьким місцем. Рішення: кешування DNS-запитів у Redis та використання декількох DNS-провайдерів з Round-Robin, щоб розподілити навантаження та підвищити відмовостійкість.
• Дедуплікація (Efficiency):
  • Уникнення повторного завантаження однакових URL: Перевірка наявності URL у метаданих перед додаванням до черги.
  • Уникнення повторного парсингу однакового контенту: Хешування HTML (наприклад, MD5) та перевірка наявності хешу. Спікер порівнює варіанти: глобальний вторинний індекс (GSI) у DynamoDB (log n, надійно) або Redis Set (O(1), швидше, але потребує ~200 ГБ для 10 млрд хешів). Використання Bloom Filter (як часто пропонують кандидати) спікер вважає поганим варіантом без обґрунтування, оскільки він дає хибнопозитивні результати (можна втратити унікальний контент), а пам'ять не є критичним обмеженням у даному сценарії.

5. Висновки / Headline

Успішний дизайн веб-краулера на співбесіді полягає не в запам'ятовуванні готового рішення, а в умінні системно мислити: спочатку побудувати просту систему, яка задовольняє базові функціональні вимоги, а потім послідовно, через призму нефункціональних вимог (відмовостійкість, ввічливість, ефективність), поглиблювати та вдосконалювати архітектуру, демонструючи практичне розуміння компромісів (trade-offs) та реальних обмежень.