Requirements

In one line: two requirements in this chapter describe the same feature differently, and the difference is the one that separates every modern feed from its predecessor.

Functional requirements

Chronological in the requirement, ranked everywhere else

The news feed requirement says "in chronological order." But two other places in the same chapter say otherwise:

The same sentence adds "users can also view suggested and promoted photos." Suggested content is not chronological — it is selected by relevance, and promoted content is auctioned. So the feed is already a merge of chronological posts plus injected non-chronological ones.

The search section notes: "Instagram ranks search results by reach (likes and views)." So ranking machinery exists in the system; it is simply not applied to the feed in this description.

And in reality Instagram's feed is famously ranked, not chronological — that change is one of the most-discussed product decisions in social media.

Why the distinction matters architecturally, from the newsfeed chapter:

Reading the requirement literally makes the design much simpler than the product it describes. The honest framing for an interview: specify chronological if you want a timeline, and say "ranked" if you want a feed — and know that ranking removes the natural sort key that makes pagination easy.

Search by caption and location, ranked by reach — a small note with a big implication

Instagram ranks search results by reach (likes and views). For example, a search for "London" displays posts in descending order of popularity. Results are paginated to support infinite scrolling.

Three things follow.

Search needs an inverted index over captions and hashtags, which nothing in the component list provides. The building blocks name a database, blob store, cache, CDN, load balancer, and task scheduler — no search index. That is a real gap, and it is the same one that building block had.

Ranking by reach couples search to the counter service. The like and view counts that Lesson 11 handles with sharded counters are also the search ranking signal, which means those counters are on more critical paths than the feed alone.

Popularity ranking is self-reinforcing. Posts that rank high get seen, get more likes, and rank higher. That is the same feedback loop the newsfeed chapter identified in its ranking service, appearing here in search — and it argues for blending in recency and relevance rather than reach alone.

Non-functional requirements

Durability is the requirement that separates this from every previous chapter

"Any uploaded content should never get lost."

That word — never — is doing something no requirement in this module has done before, and it deserves emphasis.

Compare what "losing data" means across the chapters:

A user's only copy of a photo may be the one they uploaded. There is no source to regenerate it from, no downstream system that can recompute it.

That forces a genuinely different storage posture: multi-region replication before acknowledging the upload, erasure coding or replication factors chosen for durability rather than availability, background integrity scrubbing, and versioned backups.

It also sets up a tension with the consistency requirement, which says content may take time to appear in distant regions. Both can be true, and the resolution is precise: durably stored immediately, visible eventually. The write is replicated for safety before acknowledgement; its propagation into feeds is what may lag.

Durability and consistency are different guarantees, and a media platform needs the first far more than the second.

The consistency requirement is well-stated, and the evaluation later forgets it

"We can compromise a little on consistency. It is acceptable if the content takes time to show in followers' feeds located in a distant region."

That is a good statement — it names the guarantee being relaxed and gives the concrete scenario. Same quality as the newsfeed chapter's PACELC framing.

Worth flagging now because Lesson 12's evaluation walks it back, claiming consistency is achieved because "blob stores and databases maintain data integrity." Data integrity is not consistency — integrity means the bytes are uncorrupted, consistency means all readers see the same value at the same time. The requirement here correctly chose to relax the second, and the evaluation should have said so rather than claiming it.

The stories question the design poses is a good one

Suppose we wanted to implement a time-based expiration feature (like Snapchat). What functional requirements would we need to add or remove?

Worth answering, because Lesson 10 implements exactly this and the requirements analysis is instructive:

Add: content has a time-to-live; expired content is not returned by feed, search, or profile queries; expired media is deleted rather than merely hidden.

Remove or modify: the durability requirement — "content should never get lost" — now has an explicit exception. Ephemeral content is content you have promised to lose.

That is the interesting part. The two requirements are in direct conflict, and resolving them means data is classified by lifecycle at write time: permanent posts get maximum durability, stories get a TTL and cheaper storage.

When a product adds ephemerality, "never lose data" stops being a system-wide property and becomes a per-object policy.

Naming eventual consistency as acceptable is not a throwaway — it is the permission slip for everything asynchronous in the design. Without it, fan-out has to be synchronous and the write path collapses.

Next: the estimation, and its three answers to one question.