Design Google News

01The design, in the six-step framework

1. Requirements

Functional

• Ingest articles from tens of thousands of publishers as they are published; group articles about the same event into a story; rank stories for a front page and per section (world, business, sport).
• Personalise ranking for signed-in readers (topics and sources they engage with) without creating a filter bubble.
• Show breaking news within minutes; de-duplicate syndicated copies; show source diversity within a story.
• Out of scope: hosting article text, comments, the fact-checking process.

Non-functional

• 100,000 new articles an hour at peak; 1 million active stories; 500 million users, 100 million daily.
• Front page load under 300 ms; a breaking article reaches the front page within 5 minutes of publication.
• The ranking must be explainable and auditable; publishers must be treated consistently.
• Interviewers at Google reportedly steer this question toward ranking and relevance rather than raw scale.

2. Core entities

• Publisher: id, feeds, trust and quality signals, locale.
• Article: id, publisher, URL, title, extracted text, published-at, language, entities, embedding, story id.
• Story: id, centroid embedding, first-seen, last-updated, article count, lead article, topic labels, velocity.
• Reader profile: user id, topic affinities, followed sources, recent reads (with retention limits).

3. API

• GET /front?locale=&section= → ranked stories, each with a lead article and 3 to 5 diverse sources.
• GET /stories/{id} → all articles in the story grouped by viewpoint or source, timeline of updates.
• POST /events → impressions and clicks for learning (batched from the client).
• Ingest: publishers push via sitemaps and feeds; POST /ingest/notify for push-based publishers.

4. High-level design

An article from publication to the front page:

1. The feed crawler polls feeds and sitemaps at a rate set per publisher (seconds for wire services, minutes for weeklies) and pushes new URLs onto the stream; the fetched page is parsed to text.
2. Understanding workers classify the section and language, extract entities (people, places, organisations), and compute an embedding.
3. Clustering queries the centroid index for the nearest active stories; if the best match is within a threshold and shares key entities and a time window, the article joins that story and the centroid updates; otherwise a new story is created.
4. Ranking runs a base ranking per locale and section every minute from story features and writes it to the cache; a personalised request re-ranks the cached candidates with the reader's profile.

5. Deep dives

How are articles grouped into stories, and how is it kept correct over time?

A story is a cluster in embedding space constrained by entities and time. Incremental assignment (compare each new article with the nearest existing centroids) is fast but drifts: two stories about the same event started on different continents never merge, and a long-running story's centroid wanders. So the pipeline is two-speed: online assignment for freshness, and a periodic batch re-clustering of the last day's articles that merges and splits stories and remaps article ids, publishing a new story table version atomically. Thresholds are tuned per language, and syndicated copies (the same wire text under many publisher names) are detected first by near-duplicate text hashing so they count as one article with many sources rather than many articles.

Ranking: what makes a story go to the top, and how is it explainable?

Score a story, not an article, from a small set of named features: freshness (time since the latest update), velocity (articles added per hour, with a burst detector), source authority and diversity (how many independent outlets, weighted by quality), section fit, and reader engagement signals aggregated with a delay to avoid feedback loops. Combine them in a staged ranking: a cheap linear base score selects a few hundred candidates per section every minute; a learned model re-ranks them; editorial rules (no two stories from the same cluster adjacent, minimum source count for breaking news) apply last. Every ranked story carries its feature values, so an auditor can ask why a story ranked where it did, and publisher treatment is consistent because publisher features are the same for everyone. The interviewer who says "I am not interested in scale, tell me about relevancy" wants this list and the reasoning behind each feature.

Personalisation without a bubble

A personalised front page re-ranks the base candidates with the reader's topic affinities and followed sources, but with two constraints: a fixed share of slots (the top stories of the day) is not personalised, and diversity is enforced across topics and viewpoints in the re-ranked list. Profiles are built from clicks and dwell time with decay and are stored with strict retention; a reader can see and reset them. Re-ranking a few hundred candidates with a small model costs a few milliseconds, which is how 25,000 personalised loads a second fit the 300 ms budget: the heavy work (clustering, base ranking) is shared, the per-user work is light.

Breaking news in five minutes

The budget: feed poll interval (seconds for high-velocity publishers, driven by push notifications where supported), fetch and parse (seconds), understanding and clustering (seconds), and the one-minute base-ranking cadence. A velocity detector watches story growth and can trigger an out-of-cycle ranking refresh for a section when a story accelerates. The front-page cache holds the base ranking per (locale, section) with a one-minute TTL and is replicated to every region, so a refresh propagates quickly and readers never wait on the pipeline. Corrections and retractions are a special path: an article flagged by its publisher is demoted or removed within one ranking cycle.

Serving story pages and the source list

A story page shows the lead article, a timeline of updates and a handful of sources chosen for diversity: different publishers, different countries where relevant, and at least one local outlet for local stories. That selection is precomputed when the story changes and stored with the story, so the page is one read plus a batched fetch of article headers. Article text is never hosted; the page links out, which keeps storage small (headlines, snippets, embeddings and entities only) and keeps the system on the right side of publisher agreements, a point worth one sentence in the interview.

6. What a strong answer sounds like

• Recognise that the scale is modest and the hard problems are clustering and ranking; say so early and spend the time there.
• Define a story as a constrained cluster and describe the two-speed assignment and re-clustering.
• List concrete ranking features, the staged pipeline and the editorial constraints, and explain auditability.
• Separate shared heavy computation from light per-user re-ranking to meet the latency budget.
• Expect follow-ups on multilingual stories (cross-lingual embeddings), on paywalled sources, on misinformation signals, and on measuring ranking quality offline.
• Common mistake: presenting a generic feed system with fan-out and skipping how stories are formed and ordered.

02Where this question was reported

• IGotAnOffer · SWE: 'front page for a news source that aggregates sources across newspapers'
• DesignGurus · 'Google News (News Aggregation Feed)'
• PracHub · 'News Aggregator That Clusters Articles into Ranked Stories', Senior+, Oct 2026
• Hello Interview · News Aggregator breakdown tagged Google
• LeetCode Discuss · Additional round: TikTok-style Google News; reached ideal solution in 30 min (search snippet)
• Blind · Google News; interviewer not interested in scale but in ranking and relevancy strategy
• LeetCode Discuss · Very vague prompt related to news generation with scattered requirements; No Hire for not discussing multiple approaches (search snippet)
• 1point3acres · Onsite included a news feed design plus an EC2-metrics design (search snippet)
• grokkingsystemdesigninterview.com · Most Common / L4 lists.