Design a web search engine like Google: system design interview question

How the interviewer opens it

“Design a web search engine that retrieves and ranks relevant web pages. It must support a massive collection, fresh results, and low query latency.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Corpus
Queries and traffic
Fetch volume and read:write mix
Freshness
Latency
Relevance
Consistency and availability
Durability
Site access
Scope limits

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Discover and fetch public web pages within each site's limits
Add, update, and remove pages from the search index
Rank pages for keyword queries
Return titles, URLs, and text snippets with low latency

Usually out of scope

Ads and payments
Personal results
Image and video search
JavaScript execution
Model training

What interviewers ask about

Finding matching pages: Common terms match millions of pages. The service must select useful results without scoring every page.
Page changes in search results: Page changes must reach results quickly. Queries must not mix terms, titles, and snippets from different page versions.
Page discovery and site limits: The web contains duplicate URLs and endless paths. Important changes compete with slow sites and limited fetch capacity.
Search at scale: A query can require work across a large corpus. One slow dependency can delay all results, while spare capacity increases cost.

Common mistakes

The query service scans every page and relies on a cache to meet latency targets.
The design omits page discovery and index updates.
The crawler gives every page the same fetch schedule.
The capacity estimate ignores work per query and slow dependencies.
The result combines term matches from one page version with titles or snippets from another.
The candidate spends the interview on model training instead of search system behavior.

The bar by level

Senior (L5/E5): Connects site limits, durable updates, complete page versions, and query deadlines. Preserves matched versions through metadata reads. Explains comparable scores, replica capacity, and worker recovery.
Staff (L6+/E6+): Quantifies query distribution costs and allocates the freshness budget. Defines overload behavior and capacity after zone failure. Defines version retirement across replicas, active queries, and caches. Explains trade-offs among relevance, completeness, latency, and cost.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design a web search engine like Google
Reported date not specified
Source snapshot: Nov 12, 2026
View source

Scope of a strong answer

Core requirements

Discover and fetch public web pages within each site's limits
Add, update, and remove pages from the search index
Rank pages for keyword queries
Return titles, URLs, and text snippets with low latency

Usually out of scope

Ads and payments
Personal results
Image and video search
JavaScript execution
Model training

What interviewers ask about

Finding matching pages

Common terms match millions of pages. The service must select useful results without scoring every page.

Page changes in search results

Page changes must reach results quickly. Queries must not mix terms, titles, and snippets from different page versions.

Page discovery and site limits

The web contains duplicate URLs and endless paths. Important changes compete with slow sites and limited fetch capacity.

Search at scale

A query can require work across a large corpus. One slow dependency can delay all results, while spare capacity increases cost.

Common mistakes

The query service scans every page and relies on a cache to meet latency targets.

The design omits page discovery and index updates.

The crawler gives every page the same fetch schedule.

The capacity estimate ignores work per query and slow dependencies.

The result combines term matches from one page version with titles or snippets from another.

The candidate spends the interview on model training instead of search system behavior.

The bar by level

Senior (L5/E5)

Connects site limits, durable updates, complete page versions, and query deadlines. Preserves matched versions through metadata reads. Explains comparable scores, replica capacity, and worker recovery.

Staff (L6+/E6+)

Quantifies query distribution costs and allocates the freshness budget. Defines overload behavior and capacity after zone failure. Defines version retirement across replicas, active queries, and caches. Explains trade-offs among relevance, completeness, latency, and cost.