Push to followers

Before you start

• Queues

  Slow work leaves the request path through a queue.

  Open lesson

Why it matters

A normal author has about 200 followers, and each follower expects the post in home within a few seconds. Updating all 200 homes before replying makes author latency depend on follower count, while doing no preparation makes every reader repeat the merge. The post call must return after one durable write, without waiting for 200 timeline updates.

A user with 200 followers posts. Home for those followers should include it within a few seconds. The post call should return quickly.

Input

followers = {"ana": ["bo", "cy"], "bo": ["cy"]}, cap = 3

Output

{"bo": [[3, "ana: again"], [1, "ana: hello"]], "cy": [[3, "ana: again"], [2, "bo: hi"], [1, "ana: hello"]]}

For Ana’s normal post and 200 followers, commit the post once, enqueue its id, then let a worker prepend it to 200 timelines; POST returns early and each follower’s home remains one paged read. A unique (user, post) write makes retries safe.

POST /posts commits the post row and enqueues its post id and author id. A worker loads the author’s 200 followers, prepends that post id to each user-keyed timeline, and trims each list to its newest entries. The trace assumes one delivery; production uses a unique (user, post) write so a retry cannot insert a duplicate.

GET /home reads one cursor page from the reader’s already ordered timeline. A follower who opens before their worker update sees the previous page and receives the post after the few-second freshness window. Reads become cheap, but every normal post now costs 200 background writes.