Evaluation
In one line: the evaluation is unusually honest by this module's standards — no consistency non-sequitur, no technique credited on both sides of a trade-off. What it lacks is any mention of the mechanisms the chapter is actually built on.
Requirements compliance
| Requirement | Detail |
|---|---|
| Scalability | Load balancers, web servers, and other servers are added/removed on demand |
| Fault tolerance | Replication of users' metadata, posts, and newsfeed. Redundant resources handle server failure. Monitoring observes system health and assists incident response |
| Availability | Redundant servers and replicated data. When a user disconnects, the session is re-created via a load balancer with a different server. Data is stored on redundant database clusters |
| Low latency | Geographically distributed servers and caches bring the service close to users. CDNs for frequently accessed newsfeeds and media content |
What this evaluation gets right that its predecessors did not
Worth affirming before criticizing, because three chapters in a row got this wrong.
It does not claim strong consistency. Lesson 2 chose availability over consistency via PACELC, and the evaluation does not quietly walk that back. Compare Yelp, which claimed fault tolerance implied consistency, and Uber, which credited synchronous replication with delivering both availability and consistency.
It does not credit one technique for opposing requirements. Replication appears under fault tolerance and availability — which are genuinely aligned — and not under consistency, where it would have been contradictory.
It names session re-creation. "When a user gets disconnected, the session is re-created via a load balancer with a different server" is the stateful protocol over stateless servers property from that building block, stated correctly.
So the failures here are omissions rather than errors, which is a better class of problem.
The evaluation never mentions any of the chapter's actual mechanisms
Read the four rows again and notice what is missing. Every technique listed — load balancers, replication, redundancy, geographic distribution, CDNs — would appear verbatim in the evaluation of any system in this course.
None of the following appear:
| Mechanism | Where it came from |
|---|---|
| Precomputation of feeds | The entire generation service |
| The materialized-view cache | Lesson 11's seam |
| Fan-out strategy | Lesson 4 — the chapter's largest cost |
| The active/lapsed reader split | Lesson 8 — the largest saving |
| Storing references not values | Lessons 3 and 9 |
| Ranking as a funnel | Lesson 10 — the dominant compute |
Take low latency specifically. The evaluation credits geographic distribution and CDNs. But the reason a feed loads fast is that it was computed hours ago and is sitting in a cache — precomputation is the latency answer, and it is unmentioned.
Take scalability. "Servers are added and removed on demand" is true of any stateless tier. What actually makes this system scale is the hybrid fan-out that stops a page with ten million followers from generating ten million writes, and the reader-side split that avoids computing feeds nobody reads.
This is the same pattern as that building block, whose performance section credited caching and skipped the quadtree, and that building block, whose latency section covered 0.16% of the budget.
When an evaluation lists only techniques that would apply to any system, it is evaluating a generic architecture rather than the one you designed. The test is simple: if you could paste the evaluation into a different chapter unchanged, it is not evaluating this design.
The scaling question
You're the tech lead. We have 500 million daily active users, expected to double next year. Which approach would you prioritize?
(a) Add more powerful servers to our infrastructure. (b) Shard the data across multiple database instances.
Sharding is the intended answer, and neither option is what actually breaks first
The intended answer is (b), and the standard reasoning is right as far as it goes: option (a) is vertical scaling, which has a hard ceiling, costs superlinearly, and leaves a single point of failure. Sharding scales horizontally and indefinitely.
But both options are about data storage, and Lesson 3 established that storage is not this system's constraint. Doubling the users doubles:
| Quantity | Growth | Is it the problem? |
|---|---|---|
| Storage | 2x | No — sharding handles it |
| Read requests | 2x | No — stateless tier, add servers |
| Fan-out writes | ~4x | Yes |
| Ranking compute | ~4x | Yes |
The last two are the answer, and they grow quadratically, not linearly.
Why quadratic: fan-out cost is posts × connections. Double the users and you get twice as many posters, and each user's connection count tends to grow with the network — more people to follow. Lesson 4's arithmetic scales on both terms.
So the honest answer to the question is: shard, yes — but sharding the database is not what saves you. What saves you is:
- Tightening the fan-out hybrid — lower the celebrity threshold as the network grows.
- Shrinking the precompute set — fan out to a smaller active fraction.
- Cheapening the retrieval stage so the ranking funnel sees fewer candidates.
A scaling question about a feed system that is answered in terms of databases has missed where the cost is. That is worth saying, because the question as posed invites exactly that answer.
What the design never addresses
Five gaps, in order of consequence:
No feed-quality evaluation. Lesson 11's point. The system's entire value is which 200 posts it selects, and nothing measures whether it selected well — no A/B framework, no offline evaluation, no counterfactual logging. It can be perfectly healthy and produce a bad feed.
No seen-state. Lesson 10 noted a ranked feed is non-deterministic, so "refresh" produces a different order. Without tracking what a user has already seen, refreshes will re-show content. Nothing in the schema stores it.
No cursor in the API. Lesson 6's gap — getNewsfeed(user_id, count) cannot paginate a growing feed correctly.
No fan-out mechanism. Six words in the entire chapter, which is why Lesson 4 had to be authored.
No cold-start path. A brand-new user follows nothing, so aggregation yields an empty feed. Every real platform needs a discovery path for this, and it is a different system — closer to TikTok's pure-recommendation model from Lesson 1.
The first is the most serious, and it is the same omission that building block had: a system whose output quality is the product, with no mechanism for evaluating output quality.
Worth noting that the celebrity problem is attacked twice in this design, at different layers: the hybrid stops a viral author from overwhelming the write path, and the replicated cache stops a viral post from overwhelming the read path. They are different problems that happen to share a cause.
Key takeaway
This evaluation is honest by the module's standards — it does not claim strong consistency, does not credit one technique for opposing requirements, and correctly names stateless session re-creation. Its failure is omission: it lists only techniques that would apply to any system, and mentions none of precomputation, the materialized-view cache, fan-out strategy, the active/lapsed split, references-not-values, or the ranking funnel. If you could paste an evaluation into a different chapter unchanged, it is not evaluating your design. And the scaling question's options are both about storage, when doubling the users grows fan-out and ranking roughly quadratically — so the answer is to tighten the hybrid and shrink the precompute set, not to shard.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "Replication and redundancy for availability, horizontal scaling for load, and CDNs plus geographic distribution for latency." |
| L5 | Names the real mechanism: "latency comes from precomputation — the feed was ranked hours ago and sits in a cache. The CDN helps with media, but the feed itself is personalized and can't be edge-cached." |
| Staff+ | Reframes the scaling question: "doubling users doubles storage and reads, which sharding and stateless scaling handle. But fan-out and ranking grow closer to quadratically, because you get twice the posters and each user's connection count grows with the network. So the levers are lowering the celebrity threshold, shrinking the precompute set to a smaller active fraction, and cheapening retrieval so the ranking funnel sees fewer candidates. I'd also flag that nothing here evaluates feed quality — the system can be perfectly healthy and produce a bad feed, and there's no A/B framework or offline evaluation anywhere in the design." |
Next: the whole design under interview conditions.