Evaluation

In one line: the evaluation is six sentences, and one of them repeats an error that three previous chapters in this module also made. Recognizing it by now should be automatic.

Requirements compliance

'Data integrity' is not consistency — and the requirement had already relaxed it

This is the fourth chapter in this module to fumble the consistency row, and it fumbles it in a new way.

"Blob stores and databases maintain data integrity across the system."

Integrity means the bytes are not corrupted — checksums match, writes are not torn, storage does not silently rot. It is a durability property.

Consistency means all readers see the same value at the same time. It is about agreement between replicas.

A system can have perfect integrity and no consistency at all: every replica holds uncorrupted data, and they disagree with each other.

What makes this worse than the earlier chapters' versions is that Lesson 2 already got it right. The requirement said: "We can compromise a little on consistency. It is acceptable if content takes time to show in followers' feeds located in a distant region."

That is a correct, well-scoped statement of eventual consistency. The evaluation then claims consistency is achieved — quietly reversing a decision the requirements deliberately made.

The accurate row would read:

Consistency: eventually consistent by design. Media is durably replicated before acknowledgement, but propagation into distant-region feeds may lag. Read-your-own-writes is preserved for a user's own posts.

Collecting the module's record: Yelp claimed fault tolerance implied consistency. Uber credited synchronous replication with delivering both availability and consistency. Newsfeed got it right via PACELC. Instagram relaxes it correctly in the requirements and claims it in the evaluation.

Name the guarantee you provide, not the one that sounds strongest — and if your requirements already relaxed it, do not take it back.

Durability is the row that is genuinely right, and it matters most here

"Persistent storage with automated backups ensures uploaded content is never lost."

This is correct and it is the requirement that distinguishes this chapter. Lesson 2 made the case: a user's photo may be irreplaceable, unlike a driver location that regenerates in four seconds or a timeline entry recomputable from its source.

What the row could add:

Replication before acknowledgement. Durability requires the write to be safely stored before the user is told it succeeded. Acknowledge-then-replicate loses data on a crash in between.

Erasure coding. At Lesson 3's volumes, three-way replication of exabytes is expensive; erasure coding gives comparable durability at a fraction of the storage cost, which is standard in blob stores at this scale.

Integrity scrubbing. Background verification that stored bytes still match their checksums — because at exabyte scale, silent corruption is a statistical certainty rather than a possibility.

And the tension Lesson 10 raised: Stories are content you have promised to lose, so "never lost" is a per-object policy, and the backup strategy has to honour the exception.

The evaluation never mentions the mechanism the chapter is built around

Read the six rows again. Every technique named — read/write splitting, sharding, caching, CDNs, replication, backups, load balancing — would appear in the evaluation of any system in this course.

Absent entirely:

Take latency specifically. The row credits "caching and CDNs." But the reason a feed loads fast is that it was precomputed by push fan-out and is sitting in a key-value store as a list of links. That is the latency answer, and it is unmentioned — despite being the subject of two full lessons.

Take scalability. Read/write splitting and sharding are true and generic. What actually lets this system scale is the hybrid, which stops an account with 400 million followers from generating 400 million writes per post.

Same pattern as the newsfeed chapter, whose evaluation also omitted its own mechanisms. If you could paste an evaluation into a different chapter unchanged, it is not evaluating your design.

What the design never addresses

Five gaps, in order of consequence.

Transcoding. 35 million videos a day need converting to multiple resolutions before the CDN can serve them adaptively. Missing from the components, the estimate, and the evaluation — despite being the tier that makes a video platform work.

Search infrastructure. "Search by captions and location, ranked by reach" needs an inverted index, a geo index, and a ranking pass. Described as a database read.

The hybrid threshold. Lesson 9's point — the design gives a range ("a few thousand" versus "hundreds of thousands") rather than a rule, and does not mention the reader-side split that is the larger saving.

Feed ordering. Lesson 2's contradiction — chronological in the requirement, ranked everywhere else. The design never resolves which it is building, and the choice determines whether generate_timeline works as a cursor.

Monitoring. No component observes system health.

The first is the most serious. A media platform whose design omits the media pipeline has left out the thing that makes it a media platform.

Proposing an in-memory feed store invites the obvious question, so answer it before it is asked. The failure mode is not just cold cache — it is every user's feed regenerating simultaneously, which lands on the metadata store as a thundering herd precisely when the system is already degraded.

The honest answer names persistence (append-only logging plus periodic snapshots) and replication with automatic failover, and admits the feed cache is a derived structure: it can always be rebuilt, so the goal is bounding recovery time rather than never losing it.

Interview signal by level

Next: the whole design under interview conditions.