Design a ranked social feed service. Users publish content, follow other users, and request a feed containing recent candidate posts in ranked order. The workload is read-heavy. New content may take a few seconds to reach followers, and the ranking model itself is outside scope. A user's own new post must nevertheless appear immediately in that user's feed. ### Constraints & Assumptions - The system must handle ordinary users as well as publishers with extremely large follower sets. - Feed entries may store a content identifier and ranking score; the canonical content body can live elsewhere. - A bounded recent inbox is acceptable if older material can be fetched through a slower path. - The answer should distinguish durable facts from caches and materialized feed views. ### Clarifying Questions to Ask - What are the expected publish and feed-read rates, typical follow counts, and largest follower count? - How stale may another user's post be, and how many feed items does one request return? - Are deleted posts, privacy changes, and follow or unfollow events required to take effect immediately? - Is pagination snapshot-consistent, or may newly ranked posts move between pages? ```hint Avoid one fan-out policy for every author Precomputing follower inboxes favors reads, but a publisher with millions of followers can make one write unbounded. ``` ### What a Strong Answer Covers - A hybrid push/pull architecture and a concrete rule for routing high-fan-out publishers to the pull path. - Durable content and follow data, lightweight per-user inbox entries, asynchronous fan-out, and bounded storage. - Feed assembly, ranking, caching, pagination, and read-your-writes handling for the author. - Idempotency, retries, hot keys, deletion or privacy filtering, observability, and recovery from a missed fan-out event. ### Follow-up Questions - How would you absorb a sudden burst from a publisher with millions of followers? - How can a user see their own post immediately without making all fan-out synchronous? - How would you repair inboxes after discovering that one fan-out worker lost a range of events?