Design a Neighborhood Newsfeed: Consistency Trade-offs and Paging a Black-Box Ranker

Design the home newsfeed for a neighborhood social network such as Nextdoor, where members see posts from their local community and scroll through them as an infinite, ranked feed. The interviewer pushed hardest on two areas, which are Parts 2 and 3 below: the data consistency trade-offs, and how to paginate the feed with caching when the ranking is done by a separate layer that you must treat as a black box. ### Constraints and Clarifications - Not given: user and post volumes, latency targets, how far a feed reaches beyond the member's own neighborhood, and the ranking layer's latency and limits. Ask, or state your assumptions. - Assume the ranking layer takes a user and a set of candidate posts and returns them in ranked order. You cannot change it or see its scores, and you cannot assume it returns the same order twice. ### Clarifying Questions - Does a member's feed draw only on their own neighborhood, or also on nearby neighborhoods, groups or people they follow? - How many members does a neighborhood have, and how many posts does a busy neighborhood produce in a day? - How quickly must a new post reach neighbors' feeds, and how quickly must a deleted or reported post disappear? - Are there post types that must bypass ranking or stay pinned at the top? ### Part 1 — Core feed design Design the feed end to end: creating a post, assembling a member's feed, the data model and the APIs. ```hint Who sees a post Work out what decides a post's audience in a neighborhood product and how that differs from a follower graph; it changes where the fan-out cost lands. ``` #### What This Part Should Cover - Requirements and rough estimates for posting and feed reads - How candidate posts for a member are gathered, and the fan-out strategy that follows from the audience model - The data model, the write and read paths, and the APIs ### Part 2 — Data consistency trade-offs Decide how fresh each kind of data in the feed must be and what it costs to make it fresher: new posts from neighbors, a member's own new post, edits, deletions and moderation removals, reaction and comment counts, blocks, and a member moving to another neighborhood. ```hint Not all staleness is equal Rank the feed's data by the harm a stale value causes. A post that should have disappeared and a like count that is slightly low are not the same problem. ``` #### Clarifying Questions for this Part - Must authors see their own post in their feed immediately after posting? - Is it acceptable for a removed post to remain visible to someone who already loaded it? #### What This Part Should Cover - A per-data-type consistency decision with its justification and cost - Read-your-own-writes for authors - How removals reach feeds, including content that is already cached ### Part 3 — Paginating a black-box ranked feed with a cache Members scroll page by page. Design the pagination so that, within one scrolling session, nobody sees the same post twice or silently misses one, using caching, given that you cannot change the ranking layer and its order can change between calls. ```hint Hold something still If the ranker can return a different order on every call, decide what has to stay fixed while one person scrolls, for how long, and where it can live. ``` #### Clarifying Questions for this Part - How long does a ranking call take, and how many candidates can one call rank? #### What This Part Should Cover - Why offset pagination over repeated ranking calls produces duplicates and gaps - The cached structure, its key, size, expiry and cursor design - What stays fresh within a stable order, and what happens when the cache entry expires or new posts arrive mid-session - Behavior when the ranking layer or the cache is slow or unavailable ### What a Strong Answer Covers - Settles the audience model, scale and freshness goals before choosing a fan-out strategy - A feed pipeline with clear write and read paths, data model and APIs - An explicit consistency decision per data type, including read-your-own-writes and fast removal - Stable pagination over a non-deterministic black-box ranker using a cached ranked list and opaque cursors - Cache sizing, expiry and invalidation, with graceful degradation when the ranker or the cache fails - Monitoring of freshness, duplicates across pages and ranker latency ### Follow-up Questions - The ranking layer is down or very slow. What does the feed show, and how do you keep pagination consistent once it recovers? - A member scrolls for a long time and the cached state for their session expires. What do they see next, and how do you avoid repeats? - A reported post must disappear from every feed quickly, including feeds whose pages are already cached. How? - One neighborhood suddenly becomes very active, for example during a local emergency. Which part of your design becomes the hotspot, and how do you protect it?