In a fanout-on-write home timeline, what is gained and lost by skipping inbox writes for followers inactive for several weeks?

## Why skip anyone at all In **fanout-on-write**, every post is written into the precomputed inbox of every follower. That work only pays off if the follower reads the inbox. Follower lists accumulate dormant accounts over years: people who signed up, followed some accounts, and stopped visiting. Writing into their inboxes is pure cost: - **CPU and write throughput** spent by fanout workers; - **memory** held by inboxes that are never read; - **longer fanout jobs**, which raise delivery lag for active followers. Illustratively, if 40% of follower edges point at accounts inactive for over 30 days, skipping them removes about 40% of all fanout writes in one change. ## How the skip works 1. Maintain an **activity marker** per user, updated when they open the app, for example a last-seen timestamp or membership in an "active in the last N days" set. 2. Fanout workers check the marker for each follower batch and write only to active users. 3. Inboxes of users who fall out of the active set are **expired**, freeing memory. The check must be cheap because it runs for every follower of every post. A compact membership structure, such as a bitmap indexed by user ID, keeps the per-follower check fast. A bloom filter would also work if a small rate of false positives, meaning a few wasted writes, is acceptable; it never causes a skipped active user, because bloom filters have no false negatives, provided every user is added the moment they become active. Since a bloom filter cannot delete entries, it is rebuilt periodically to drop users who went dormant. ## What happens when the user returns The returning user's inbox is missing or out of date, so the first timeline request takes a **rebuild path**: 1. Mark the user active immediately, so new posts start being pushed to them. 2. Run a **fanout-on-read** pass: fetch recent posts from each followee's outbox and merge them by time. 3. Serve the first page from that merge. 4. Write the merged result back as the user's inbox, then continue normally. Ordering matters. If the user is marked active **after** the rebuild reads the outboxes, a post published in between is neither in the rebuild nor pushed to them. Marking active first, then rebuilding, and deduplicating by post ID closes that gap. ## Costs and failure modes | Gain | Loss | |---|---| | Fewer fanout writes | Slower first load for returning users | | Less inbox memory | A rebuild path that must be built and tested | | Lower fanout lag for active users | A race between rebuild and resumed fanout | | Cleaner capacity model | Rebuild storms when many users return together | The **rebuild storm** deserves attention. A mass notification or a re-engagement email can bring back millions of dormant users within minutes, each triggering an expensive pull merge. Mitigations include: - serving a lightweight pull-based page first and rebuilding the full inbox in the background; - rate-limiting rebuilds and queueing them; - pre-warming inboxes for the users targeted before a campaign is sent. ## Choosing the inactivity window - A **short window** saves more writes but sends more users down the slow rebuild path. - A **long window** makes rebuilds rare but saves less. - The right window comes from the return-visit distribution: pick a point after which returns are rare enough that the rebuild cost is smaller than the fanout saved. ## Where it fits This is a refinement, not a core design element. It matters once fanout volume is large enough that dormant followers show up as a real cost line, and it combines naturally with the hybrid model, which already has a pull path that the rebuild can reuse.