# Design a Scalable News Feed ## Scenario Design the home-feed system for a social product. Users publish posts, follow other accounts, and request a paginated feed of posts from accounts they are allowed to see. The interview report names only a news-feed design, so begin by clarifying scale, ordering, privacy, deletion, and freshness requirements instead of assuming them. ### Part 1: Define requirements and the data model Establish a concrete contract for publishing and reading the feed. Identify the core entities and the information needed to enforce visibility and produce stable pages. #### What This Part Should Cover - Functional operations for publishing, following, unfollowing, deleting, and reading a feed. - Whether ordering is reverse chronological, ranked, or configurable. - Scale assumptions for users, follows, post volume, feed reads, and unusually popular accounts. - Models and identifiers for users, posts, follow edges, visibility, and feed entries. - A cursor contract that remains meaningful while new posts arrive. ```hint Start at the read boundary Treat privacy rules and pagination as part of the read contract, not as details to add after choosing storage. ``` ### Part 2: Design publication and fanout Trace a post from an accepted write to its appearance in eligible followers' feeds. Compare fanout on write, fanout on read, and a hybrid. #### What This Part Should Cover - The durable source of truth for a post and how a successful write emits fanout work. - Queue partitioning, retries, deduplication, and idempotent feed-entry creation. - The latency and storage tradeoffs of push and pull approaches. - Special handling for accounts with very large follower sets. ```hint Look for a workload split Use the difference between ordinary accounts and high-fanout accounts to test whether one strategy fits every write. ``` ### Part 3: Design feed reads, ranking, and caching Explain how a request obtains candidates, applies ordering, filters inaccessible content, and returns a stable next cursor. #### What This Part Should Cover - Candidate retrieval for both precomputed and read-time sources. - Ranking or reverse-chronological merge behavior and deterministic tie-breaking. - Cache keys, invalidation or freshness bounds, and protection from hot keys. - Stable pagination without returning the same item twice because new posts arrived. ```hint Make the cursor describe order A cursor based only on page number usually cannot describe a changing ordered feed reliably. ``` ### Part 4: Handle privacy changes, failures, and operations Describe what happens when content is deleted, a user blocks or unfollows another user, or a fanout worker fails. #### What This Part Should Cover - Enforcement of deletion, blocking, audience changes, and unfollow behavior. - Recovery from delayed, duplicated, or lost-looking queue work. - Rebuilding or backfilling feed state from authoritative data. - Metrics and alerts for publish-to-visible latency, stale feeds, errors, and queue lag. - The consistency guarantees visible to users. ```hint Recheck mutable policy Identify which checks must happen on every read even when feed entries were precomputed earlier. ``` ### What a Strong Answer Covers A strong design states its assumptions, keeps an authoritative post and relationship model, chooses fanout based on workload shape, and defines stable read semantics. It explains privacy and deletion behavior, not just the happy path, and connects retries, idempotency, observability, and rebuild procedures to explicit consistency goals. ### Follow-up Questions - How would the design change for a strictly ranked feed rather than reverse chronology? - What happens when a previously private post becomes public, or the reverse? - How would you prevent a popular account from overwhelming the fanout pipeline? - How would you verify that a rebuild produces the same visible feed as the live path?