Requirements

In one line: the availability requirement here does something no previous chapter has done — it names the theorem it is invoking and picks a side explicitly.

Functional requirements

'The primary challenge is the volume of candidate content' is the sentence that defines the chapter

Most functional requirements describe what the system does. This one names the difficulty, and it is the right difficulty.

Work it out with the chapter's own numbers. An average user has 300 friends and follows 250 pages — 550 connections. If each produces a handful of posts a day:

550 connections x ~5 posts/day = ~2,750 candidate posts per day

And the feed shows perhaps 200. So the system is discarding roughly 93% of candidates, and the entire product experience is determined by which 93%.

That reframes the problem usefully. A newsfeed is not a delivery system; it is a selection system. Delivery — getting 2,750 candidates into reach — is Lesson 4's fan-out problem and has a known answer. Selection is Lesson 10's ranking service and does not.

It also explains why the requirement mentions ranking twice, in two different bullets. Ranking is not a feature of the newsfeed; it is the newsfeed.

'Affix new incoming posts for all active users' quietly assumes push

The display requirement says the system should "affix new incoming posts to the newsfeed for all active users."

That is a fan-out-on-write assumption smuggled into a requirement — it says new posts are pushed into existing feeds, rather than feeds being assembled on request.

Two things worth noticing.

"Active users" is doing important work. Lesson 4 will show that fanning out only to active users is the single largest saving available in a push design, and it appears here as an offhand qualifier rather than a design decision.

A requirement should not pick an implementation. "The user sees new posts promptly" is a requirement; "affix posts to feeds" is a mechanism. The distinction matters because Lesson 4 shows that pure push cannot work for large accounts, so the requirement as written is unsatisfiable at the extremes.

Read it as intent — feeds should update promptly — and leave the mechanism to the design.

Non-functional requirements

Citing PACELC and picking a side — the first chapter in the course to do this properly

"The system can compromise strong consistency for availability and fault tolerance, according to the PACELC theorem."

This is worth dwelling on, because the previous three problem chapters all fumbled consistency. Yelp claimed fault tolerance implied consistency. Uber credited synchronous replication with delivering both availability and consistency. Twitter got it right but informally.

Here the theorem is named and the trade is chosen explicitly.

PACELC, from the Foundations module: if there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency. It extends CAP by pointing out that the trade-off exists even when nothing has failed — a system that wants strong consistency pays for it in latency during normal operation, not just during partitions.

That second half is the relevant one here, and it is why the citation is apt. This system is PA/EL: available under partition, and latency-favouring the rest of the time.

The justification is the same as every feed system: staleness costs nothing. If your friend's post appears in my feed two seconds late, or if two of my devices briefly disagree about my feed's contents, no harm occurs. Compare a payment or a ride match, where divergence strands someone.

And notice the interaction with the 2-second latency budget in the next requirement. Strong consistency across geographically distributed replicas would mean cross-region coordination on the read path — which alone could exceed 2 seconds. The latency requirement and the consistency requirement are not independent; choosing a tight latency budget largely decides the consistency model for you.

Two seconds is generous, and it is the wrong metric

"The maximum latency should not be greater than 2 seconds."

Two observations.

Two seconds is a long time for a feed load. Users perceive delays beyond a few hundred milliseconds, and a 2-second feed feels sluggish. Compare that building block's 2–3 second budget, which was for computing a route across a continent — genuinely hard work. Loading a precomputed list should be an order of magnitude faster.

"Maximum" is the wrong word. A maximum implies a hard bound that is never exceeded, which no distributed system can promise. What you actually specify is a percentile: p99 under 500 ms, p99.9 under 2 seconds. That is measurable, achievable, and meaningful.

The distinction matters because Lesson 4's design has two very different paths:

PRECOMPUTED feed (active user)  ->  one cache read      ->  tens of ms
GENERATED on demand (lapsed)    ->  fan-out + rank      ->  hundreds of ms to seconds

A single "maximum latency" figure hides that bimodality entirely. The right specification names both: fast for the common path, bounded for the cold one.

Latency requirements should be percentiles over a named path, not a single maximum over everything.

Fault tolerance is stated as partition tolerance, which is a narrower thing

The design defines fault tolerance as "partition tolerance — system availability in the event of network failure between the system's components."

That is one kind of fault. Servers also crash, disks fail, deployments go wrong, and dependencies time out. Partition tolerance is specifically about the network splitting the system into groups that cannot talk to each other.

The narrowing is probably deliberate, to set up the PACELC citation that follows — you can only "choose availability under partition" if you have framed partitions as the fault you face.

But it leaves the more common failures unaddressed, and Lesson 12's evaluation answers them with replication and redundancy rather than anything partition-specific. In practice, single-node failure is far more frequent than a genuine network partition, and it is worth saying which you are designing for.

Next: the estimation, where the chapter contradicts its own arithmetic.