Lesson 12 of 15
36. Design a Web Crawler

Score yourself

3 min read+10 XP

Score yourself

Give yourself 0, 1 or 2 points per row.

Area0 points1 point2 points
RequirementsStarted drawingPages and linksPoliteness, freshness, duplicates and resilience agreed
EstimatesNoneNumbers, not used laterNumbers that drove async fetching, object storage and a Bloom filter
API and dataSkippedSome componentsFrontier, fetcher and store interfaces; url_state and host_state
High-level designLoop without detailsLoop with boxesLoop walked, with DNS, robots.txt, dedupe and re-crawl
Deep diveHand-wavedOne topicFrontier with per-host politeness, RFC robots rules, dedupe or host-based partitioning
Trade-offsNone namedNamed when askedRaised unprompted (Bloom false positives, split by host, trap limits)
CommunicationLong silencesMostly clearThought out loud, checked in, managed time

12 to 14: strong hire signal. 8 to 11: solid, polish the weak rows. Under 8: redo the round in a week, timer on.

The bar: fresher vs SDE-2

FresherSDE-2
FrontierA queue of URLs (BFS)Priority front queues, per-host back queues, next-allowed heap
Politeness"Respect robots.txt"RFC 9309 matching, caching rules, adaptive delays, back-off
DedupeA set of visited URLsNormalisation, Bloom filter sizing, content hashes, near-duplicates
ScaleMany workersPartition by host on a consistent-hash ring, forwarded links
ResilienceNot mentionedTimeouts, size limits, traps, per-host breakers, re-crawl scheduling

Common mistakes

  • A single BFS queue, so hundreds of requests hit one site at once.
  • Ignoring robots.txt, or parsing it with first-match rules.
  • No URL normalisation, so the same page is fetched under dozens of URLs.
  • Splitting work by URL, breaking per-host politeness.
  • Storing pages in a database instead of object storage.

Quick check

Five questions on this chapter. Pick an answer, then check it.

quiz