Design a Highly Available Social Feed and Trending System

# Design a Highly Available Social Feed and Trending System Design a large social platform where users create accounts, publish short posts, follow or unfollow accounts, view a home timeline, like, repost, and comment. The platform also surfaces trending or popular posts. Focus on home-timeline generation, high-concurrency engagement, efficient caching, horizontal scaling, and continued operation when a component fails. Compare fan-out on write with fan-out on read, and explain how the design handles a very popular account whose new post may need to reach a large audience at once. ### Constraints & Assumptions - The home timeline is primarily reverse chronological; a ranking layer may be discussed as an extension. - A newly published post should become visible quickly, but brief propagation delay is acceptable. - Post creation and the canonical follow graph must remain durable even if timeline fan-out is delayed. - Exact user counts, posting rate, follower distribution, retention, and acceptable staleness should be established with the interviewer. ### Clarifying Questions to Ask - Is the timeline strictly chronological, ranked, or a combination of both? - What freshness target applies to ordinary authors and extremely popular authors? - Are likes, reposts, and comments required to be exactly current on every read, or may displayed counts be briefly stale? - How is trending defined: global, regional, topic-specific, or personalized, and over what time window? - Which actions require strong consistency, and what behavior is acceptable during a regional failure? ### What a Strong Answer Covers - Core entities and ownership for users, posts, follows, likes, reposts, comments, timeline entries, and trend aggregates. - A complete publish path from durable post creation through follower fan-out, cache population, and client delivery. - A justified fan-out strategy, including a hybrid path that avoids materializing millions of timeline entries for extremely popular accounts. - Timeline reads that merge precomputed inbox entries with selected read-time sources while preserving order and pagination. - Redis or another cache used with explicit keys, invalidation, expiration, miss behavior, and protection against hot keys. - High-concurrency engagement writes with idempotency, counter aggregation, and a distinction between canonical events and eventually updated display counts. - A windowed trending computation that resists old cumulative popularity and can recover from delayed or duplicated events. - Partitioning, replication, stateless services, backpressure, degraded modes, multi-region choices, and observability tied to user-visible failures. ### Follow-up Questions 1. A popular account publishes to tens of millions of followers. How do you prevent the fan-out workers and timeline store from overwhelming the database? 2. How does a timeline request merge precomputed entries with posts from authors handled by fan-out on read without duplicates or broken pagination? 3. What happens when the cache for a popular post's engagement count expires while requests remain high? 4. How would you compute trending posts over several windows while limiting manipulation by one account or a burst of duplicate events? 5. Which features remain available if the timeline fan-out service is down for thirty minutes?