News feeds inside a product

The problem

A feed built on article search looks fine in testing and degrades exactly when news breaks: the same event fills the surface, and the reader sees one story twenty times on the day they most wanted a summary.

How does a news API support a news feed inside a product?

Story-level results keep the feed readable under load, and language and outlet filters let the feed match the audience rather than the index.

What the workflow looks like

1. Collapse to stories for any surface a person scans.
2. Scope by language to the audience, not to the whole index.
3. Cache per feed rather than per user; the query is the same for everyone.
4. Estimate cost from distinct queries, not from user count.

What will a news API not do for a news feed inside a product?

Responses carry a snippet and a link, so the reader leaves your product to read the article. If your design requires full text in-app, that is a publisher licensing conversation and not something an API can grant you.

The mistake teams make here

The characteristic failure is testing the feed on the popular query and shipping. Popular queries have deep, varied coverage and look fine under any configuration; the feed breaks on the narrow query with three articles and on the breaking story with four hundred near-identical ones, and neither appears in a demo. The second mistake is caching per user. The query is the same for everyone looking at the same surface, so per-user caching multiplies cost by audience size for no benefit, and teams discover this when the bill arrives rather than when the design is drawn. Estimate from distinct queries, and cache at that level.

How would you know a news feed inside a product is working?

Watch the empty state and the duplicate rate, because those are what users see. Sample the feed for your least popular query as well as your most popular one — the popular query always looks fine. A feed that returns three near-identical articles reads as broken to a user regardless of how correct it is, which is why grouping matters more here than anywhere else.

What to build in the first week

Build the empty state and the flood state before the normal one. Pick the narrowest query your product will issue, see what comes back, and design for that; then pick a day with a major story and see what the same surface looks like with one event dominating. Those two screens determine whether the feature reads as broken, and they are the two nobody builds first. Once they work, the middle case takes care of itself. It is also worth deciding in week one what the reader sees when they tap through, because a snippet and a link is what the API returns and designing around full text in-app is a licensing conversation rather than an engineering one.

What are the alternatives for a news feed inside a product?

Off-the-shelf headline widgets are faster to ship and give you no control over sourcing, dedup or ranking, which becomes the problem the moment a user complains. A licensed wire feed gives cleaner rights and much narrower coverage. Building on a search API costs more upfront and is the only option that lets you fix a bad result rather than report it.

The queries that implement it

• Build a morning digest someone will actually read — /stories in recent mode
• Follow a sector, but only in publications you trust — /stories in hybrid mode
• Follow a topic in a specific language only — /stories in semantic mode

Each recipe makes the case for its parameters. Response fields, failure modes and scheduling cost are in the technical documentation.