Step 3 is the exception the requirements demanded: the author's own timeline is written synchronously, in the request, so the user always sees their own post immediately regardless of fan-out lag. It is one extra write and it removes the most-reported class of complaint.

The fan-out worker is Module P-19's job system with three specifics:

Separate queues by fan-out size. A 5-million-follower fan-out must not occupy the workers that ordinary posts need — that is head-of-line blocking, and the answer is the same as Module P-19's: separate queues with dedicated pools, so a large fan-out is slow without making everything slow.

Batch and pipeline aggressively. Ten thousand individual ZADDs is ten thousand round trips; batches of a thousand in a pipeline is ten. This is the difference between the fan-out rate being feasible and not.

Checkpoint by follower cursor. A fan-out of two million followers is a long job, so it records how far it has progressed (Module P-19's cursor) and resumes rather than restarting — and because ZADD is idempotent, an overlap after a crash costs nothing.

The SLI for this path is post-to-timeline latency at p99, and queue depth plus oldest-job age as the leading indicators (Modules P-19, A-8). Fan-out lag is the metric users actually feel as "the feed is behind."

---

The Read Path and a Cache Hierarchy That Earns Its Complexity

A feed load looks like this:

Four to six round trips total, not twenty — because everything is a batch read by ID. That shape is what makes a 200 ms p99 achievable.

Now the insight that justifies a layered cache rather than one big one:

Timelines are private and posts are shared, so they have opposite cache economics.

So the hierarchy is not ceremony:

• L1, in-process — hot post objects and author profiles. A celebrity post read a million times a minute is served from local memory at ~100 ns rather than 0.5 ms across the network (Module F-12's hierarchy argument at its most favourable). Bounded size, LRU, short TTL to bound staleness.
• L2, Redis — timelines (sharded by user), post objects, counters, block lists.
• L3, the datastore — posts and the graph in Postgres (partitioned), or a wide-column store for timelines at the largest scale (Module P-9).
• The CDN caches media and immutable post content by content-addressed key (Module A-11) — it cannot cache a personalised feed, but the payload bytes are the bulk of the transfer.

And design the timeline store as a cache, not as a source of truth. Losing the Redis cluster should be a degradation, not a data loss: timelines are rebuildable from follows plus posts, and rebuilding a user's timeline on demand is a bounded query. That single property turns a catastrophic dependency into a recoverable one, and it is worth accepting some rebuild cost to preserve it.

---

Ranking as a System

Chronological is simple, cheap, cacheable, and what many users say they prefer. Ranked feeds exist because they measurably increase engagement, and they change the architecture:

The latency budget is the constraint. Scoring 500 candidates inside ~50 ms means the model must be cheap and, more importantly, feature lookup must be precomputed — per-user and per-post features fetched as one batch read from a feature cache, never computed per candidate. The usual first mistake is a scoring function that issues a query per candidate; at 500 candidates that is the whole budget spent on round trips.

Ranking makes caching harder. A ranked feed is a function of (user, candidate set, model version, time), so it is far less cacheable than a chronological list. The workable split: cache the candidate set (which changes only when new posts arrive) and either compute the ranking fresh or cache the ranked page for a short window.

And ranking creates a pagination bug worth naming. If the ranking is recomputed on each page request, items shift between pages, so a user scrolling sees duplicates and misses posts entirely. The fix is a session-scoped pagination token that pins the candidate set and the ranking seed for the duration of the scroll — a cursor over a snapshot, which is Module P-20's keyset-cursor argument with an added requirement that the ordering be stable, not just the position.

---

The Celebrity Problem, in Detail

One account, 100 million followers, one post. Four separate problems, and each needs its own answer.

1. Fan-out is impossible at write time. 100 M writes at 500 k/s is 200 seconds of exclusive capacity. So this account is on the pull path: its post is written once, and its followers pick it up at read time from a small per-account "recent posts" list. A user following twelve large accounts does twelve small reads.

2. The read-time cache stampede. The moment the post is published, millions of readers request the same post object, all miss, and all hit the datastore — Module P-12's thundering herd at its worst. Two mechanisms:

• Request coalescing / single-flight: the first miss fetches, everyone else waits on that one fetch. Per instance this is a few lines and removes almost all of the amplification.
• Pre-warm at publish time, which is the pleasing inversion: instead of pushing the post ID into 100 million timelines, push the post object into the caches — a few thousand writes rather than a hundred million, and it eliminates the stampede entirely. The push is to the caches, not to the timelines.

3. Engagement counters go hot. Millions of likes on one post is a single hot key, so shard the counter across N sub-keys (likes:{post}:{0..15}), increment a random shard, and sum on read — trading a slightly more expensive read for a write path that does not serialise (Module P-6's hot-partition mechanism, at the key level).

4. Its followers' timelines are unbalanced. A user following one celebrity and 199 ordinary accounts has a feed dominated by whichever path is cheaper. Re-ranking with author-diversity constraints is what stops the pull path's posts monopolising the merged result.

---

Multi-Region, Where Only One Thing Must Not Be Stale

Following Module A-9's topology: reads local, writes to the author's home region.

The design point that saves the most money: replicate the post store and the follow graph, then compute timelines locally in each region. Replicating the timeline writes themselves would be 240,000 small cross-region writes per second, which is an enormous egress bill (Module O-8) for data that is derivable. Replicate the inputs, derive the outputs locally — a general principle worth carrying beyond feeds.

Cross-region replication lag becomes feed staleness of a few seconds, which the requirements already accepted. That acceptance is what makes this whole topology cheap, and it is the payoff for stating the availability-over-consistency priority up front.

The one exception is read-your-own-writes (Module P-11). A user posting from region B must see their post immediately even if the write went to region A. Two mechanisms together: the synchronous write into the author's own timeline (step 3 of the write path), and pinning the author's session to read their own recent posts from an authoritative source for a short window. Every other kind of staleness is acceptable; this one produces "my post disappeared" and must not happen.

---

Deletes, Blocks, and Privacy: Filter at Read, Do Not Correct at Write

A post is deleted. It exists in the timelines of millions of followers. You cannot chase it — finding and removing it from 40 million sorted sets is a fan-out as expensive as the original, arriving unpredictably.

So the timeline stores IDs, and hydration is where the truth is applied:

A deleted post simply fails to hydrate. Blocks and mutes are a small per-user list checked at hydration. A visibility change from public to followers-only is evaluated at hydration. Nothing is corrected in the materialised view; stale IDs are lazily removed when encountered.

The general lesson: a denormalised, materialised view should be filtered at read time rather than corrected at write time, because correcting it costs a second fan-out with worse timing. It is the same reason Module A-11 stores an immutable object and a mutable pointer, and it is why the timeline holds IDs rather than content.

Note the requirement it creates: fetch more IDs than you need (over-fetch by a margin), because filtering removes some, and a page that returns twelve items when the user expected twenty is a visible bug.

For a genuine erasure request (Module O-9), the post row is deleted, the tombstone remains long enough for the lazy cleanup, and the media is crypto-shredded by deleting the per-subject key — which reaches every copy, including caches and backups, without rewriting any of them.

---

Failure Modes and the Degradation Ladder

The degradation ladder is the deliverable: ranked → chronological → cached-and-stale → a small "pull to refresh" state. Each step is a defined behaviour with a metric, not a stack trace. And note that "counts are missing" is a far better outcome than "the feed failed," which is the whole argument of Module A-7 in a product setting.

Why this matters in production: the feed failures that actually happen are fan-out lag nobody alerted on, a celebrity post that stalled every other user's fan-out for three minutes because the queues were shared, a like counter that took a hot row lock and made a popular post un-likeable, a delete that a support team believed had worked because they checked the post store rather than a follower's feed, and a ranked-pagination bug that showed users the same post four times. None of them is exotic; each maps to a decision in this design.

---

What We Deliberately Did Not Build

• Notifications — a separate fan-out system with different semantics (per-user, must-not-miss, so it needs the durable delivery of Modules P-19 and A-10 rather than a disposable timeline).
• Direct messages — a different data model, different privacy properties, and often end-to-end encryption.
• Search and trending — Module P-20's territory, fed by the same event stream.
• Integrity and moderation — a classification pipeline plus a read-time filter, which slots into the hydration step this design already has.
• Ads and injected content — another candidate source in the ranking stage.
• Video — Module A-11's pipeline, with the feed holding only references.

---

Summary

• State the priority first: availability and latency over consistency. A thirty-second-stale feed is fine; a slow or failed feed is not; approximate counts are invisible. This is the exact inversion of Module P-24, and nearly every decision here follows from that line — with one exception, that a user must always see their own post immediately.
• Compute the celebrity number early. One 100 M-follower post is 100 million timeline writes, or ~200 seconds of exclusive fan-out capacity, which invalidates pure write-time fan-out outright.
• Fan out on write for ordinary accounts, pull at read for large ones, and merge. The test of a good hybrid is that neither side has an unbounded term: push is bounded by followers-of-ordinary-accounts, pull by large-accounts-followed-by-one-user. Also push only to active users and rebuild an inactive user's timeline on login.
• Timelines hold post IDs, capped at a few hundred, in a sorted set scored by a time-ordered Snowflake ID — so ordering and pagination need no secondary index (Module P-3), storage stays small, and edits or deletes never have to reach millions of copies. ZADD keyed on the post ID is absolute and therefore idempotent, which makes at-least-once fan-out harmless (Module P-16).
• Never UPDATE ... likes = likes + 1. Append like events and aggregate; shard the counter for the hottest posts. A relative update on one hot row serialises every like and produces a dead tuple each time.
• The write path is: post row plus outbox in one transaction, respond, then CDC to a queue and fan-out workers — with the author's own timeline written synchronously in the request, which is one extra write that removes the most-reported complaint. Separate queues by fan-out size so a large account cannot starve ordinary posts, batch ZADDs in pipelines of ~1,000, and checkpoint by follower cursor.
• A feed load is four to six batch round trips, not twenty, because every step is a multi-get by ID. That shape is what makes a 200 ms p99 possible.
• The cache hierarchy earns its complexity because timelines are private and posts are shared: timelines have zero cross-user hit ratio and belong in a sharded Redis cluster; post objects have an extremely high hit ratio and belong in an in-process cache and Redis, with the CDN carrying media and immutable content.
• Design the timeline store as a cache, not a source of truth. Timelines are derivable from the graph plus posts, so losing the cluster becomes degraded latency rather than data loss — a property worth paying rebuild cost to keep.
• Ranking is two-stage — candidate generation then scoring then re-rank — and its constraint is the latency budget. Features must be precomputed and fetched in one batch; a query per candidate spends the entire budget on round trips. Cache the candidate set rather than the ranked result, and pin the ranking with a session-scoped pagination token, or scrolling shows duplicates and skips posts.
• The celebrity post has four distinct problems: fan-out (use the pull path), a cache stampede at publish (request coalescing, plus the inversion of pre-warming the post object into caches — thousands of writes instead of a hundred million), hot engagement counters (shard and sum), and feed imbalance (author-diversity re-ranking).
• Multi-region: replicate the inputs and derive the outputs locally. Replicating 240,000 timeline writes per second across regions is an enormous egress bill for derivable data; replicate the post store and follow graph, and compute timelines in each region. Accept the lag as staleness — except for read-your-own-writes, which needs the synchronous own-timeline write plus a short session pin.
• Filter at read, do not correct at write. A deleted, blocked, muted or newly-private post simply fails to hydrate, and stale IDs are cleaned lazily — because chasing 40 million materialised copies is a second fan-out with worse timing. Over-fetch IDs by a margin so filtering does not shorten the page. Erasure is a row delete plus crypto-shredding the media key, which reaches caches and backups without rewriting them.
• The degradation ladder is the deliverable: ranked → chronological → cached-and-stale → an honest empty state, with counts omitted rather than the feed failed. And post-to-timeline p99 is the SLI users actually feel.

That closes Phase 3. Architect has been about coordination: agreeing on a value, taking exclusive action, changing several things at once, drawing boundaries, bounding failure, and spreading across the planet. What it has not covered is running any of it — proving the breakers fire, knowing when you are violating a promise, migrating a schema under load, surviving the loss of a datacentre, funding the whole thing, and staying inside the law.

Phase 4, Production & Governance, is that. It opens with observability, because every mechanism in the last three phases has a metric that decides whether it is working, and none of them tell you on their own.

---