Design a Web Crawler: FAANG Interview Question

[00:02] massive amounts of web data, but have you ever wondered how they actually collect it all? Behind every search engine and AI model is a web crawler. A system that quietly roams the internet, visiting billions of

[00:14] pages one by one. It sounds simple. Start with a few URLs, download the pages, extract links, and keep following them. But once you try to scale this to billions of pages, things get very

[00:27] interesting. Let's design one together. Imagine we need to crawl 1 billion pages every month. That works out to roughly 400 pages per second. To handle that kind of scale, our crawler has to do several things well. It needs to be fast

[00:41] and distributed. It has to be polite, never overwhelming any single website. It should be smart about which pages to visit first, and it must keep running even when things go wrong. Because on the internet, something always goes

[00:54] the internet, something always goes wrong. complete authentication and user management platform for developers. boilerplate. Clerk gives you customizable UI components and powerful

[01:08] APIs that work with any framework. That's sign-in, user profiles, org management, even billing. In minutes, not weeks. Stop reinventing the wheel. Start shipping feature faster with Clerk. Try free today. Link in the

[01:22] Clerk. Try free today. Link in the description. a good start. You begin with a list of seed URLs, put them in a queue, then visit each one. When you fetch a page, you extract all the links and add those

[01:38] to the back of the queue, then repeat. But this basic approach breaks down almost immediately. Most pages link back to the same host. Think of Wikipedia. Every page links to other Wikipedia pages. So our crawler ends up hammering

[01:53] the same site over and over. Websites have rate limits, and if we push too hard, we'll get blocked. And that's another problem. Not all pages are equal. The Apple homepage carries a lot more value than a random post on an

[02:06] obscure forum. We can't treat every URL the same. We need a way to prioritize the important ones. So how do we fix this? The first rule of polite crawling is simple. Don't hit the

[02:19] same host too often. Instead of one big queue, we group URLs by the host. That way we can control how often we send requests to each website. websites, we can't just create a queue for each one. So we use a fixed set of

[02:33] queues, say a few thousand, and map hosts to them using simple hashing. All URLs on the same website get mapped to the same queue, and worker threads pull from these queues with delays between requests. This is how we keep our

[02:47] Next, we need to make the crawler smarter. Instead of treating every page same, we add a layer that decides what's worth crawling first. When new URLs come in, a prioritizer ranks them based on factors like how popular the page is,

[03:03] how often it's updated, and how many other sites link to it. These URLs go to what's called a frontier. Basically, the list of pages waiting to be crawled. High-value URLs get scheduled sooner, while low-value ones wait longer. In

[03:19] prioritization models can be quite advanced, sometimes even machine learning models that adapt in real time. But for now, it's enough to understand that we crawl the web strategically, not randomly.

[03:32] Another big challenge is redundancy. The internet is full of mirrored articles and reposted content. To handle that, we add two components, URL seen and content seen. The URL seen system prevents us from crawling the same link twice. The

[03:47] content seen system detects duplicate pages by hashing the text or structure Once a page is downloaded, a parser takes over. It validates the HTML, extracts useful text, and finds links to follow. From there, a link extractor

[04:03] finds new URLs, converts relative links to absolute ones, and sends them to the prioritizer. A URL filter removes anything we don't want, like image files, video links, or disallowed domains.

[04:17] And the loop continues. Download, parse, extract, filter, repeat. To reach billions of pages, we need many

[04:29] ones. We need distributed crawlers across regions, with each crawler handling part of the frontier, often close to where the target servers are located. Maintaining politeness across multiple

[04:42] distributed crawlers can be challenging. We need to deal with performance bottleneck. DNS lookups, for example, can be slow, so we cache them We need checkpointing so that if a crawler crashes, it can restart from

[04:56] where it left off. Each of these scaling challenges could easily be a topic of At this point, we've built something powerful. A crawler that can explore billions of pages, stay polite, and make smart decisions about what to fetch

[05:10] next. It's no longer just a simple loop of download and follow links. It's a distributed system that balances fairness, scale, and intelligence, quietly mapping the web behind the scenes.

[05:24] interview? Join our community where we offer comprehensive courses on system design, coding, behavioral questions, machine learning, and object-oriented machine learning, and object-oriented design. Learn more at bytebytego.com.