Swe System Design: Social Media Feed

Designing a social media feed (Twitter/X timeline, Instagram feed, LinkedIn feed) is one of the most frequently asked system design questions in 2026 SWE loops because it forces candidates to reason about fan-out tradeoffs, read/write asymmetry, ranking, and caching simultaneously. This guide breaks down the core architectural decisions interviewers expect, with the numbers that separate a strong answer from a hand-wavy one.

Requirements and Scale Estimation

Before drawing boxes, establish scale. A mid-size social platform in 2026 might have: 100 million daily active users, average 200 follows per user, celebrity accounts with 50+ million followers, and a 80:20 read-to-write ratio typical of feed systems (users scroll far more than they post).

Functional requirements: users can post content, follow other users, and view a chronological or ranked feed aggregating posts from people they follow. Non-functional requirements: feed load must return in under 200ms at p99, the system must tolerate celebrity accounts without falling over, and eventual consistency (a few seconds of staleness) is acceptable for feed freshness.

Fan-Out Strategies: Push vs Pull vs Hybrid

This is the crux of the entire design and the part interviewers probe hardest.

Fan-out-on-write (push model). When a user posts, the system immediately writes that post into the precomputed feed (a Redis list or similar) of every follower. Reading the feed is then a cheap single-key lookup. This works beautifully for the 99% of users with a normal follower count, because feed reads are the dominant operation and precomputation makes them nearly free.

Fan-out-on-read (pull model). The feed is computed at read time by fetching recent posts from everyone the user follows and merging them. This avoids the “celebrity problem” — a celebrity with 50 million followers would require 50 million writes on every single post under the push model, which is infeasible.

Hybrid approach (used by virtually every major platform in 2026). Push for normal users, pull for celebrity/high-follower accounts (typically anyone above a threshold like 1 million followers), merging both at read time. This bounds the fan-out write cost while keeping reads fast for the vast majority of accounts.

Ranking Beyond Chronological

Pure reverse-chronological feeds are largely gone from major platforms. Ranking models score candidate posts using signals such as recency decay, author affinity (how often the viewer engages with this author), predicted engagement probability (likelihood of like/comment/share), and content type diversity to avoid monotony.

In interviews, it’s enough to describe a two-stage architecture: a lightweight candidate generation stage (pull ~500 candidate posts from follow graph + CDC-driven precomputed feed) followed by a heavier ranking stage (ML model scores and re-orders the top N for final display). Mentioning this two-stage pattern signals familiarity with how production recommendation systems actually work, distinct from toy chronological designs.

Storage and Caching Layers

Precomputed feeds live in an in-memory store (Redis sorted sets are the canonical choice — score by timestamp, member is post ID). Each user’s feed cache is capped (e.g., last 800 post IDs) to bound memory. Actual post content is stored separately in a document store or wide-column store (Cassandra is a common choice given its write-optimized LSM-tree structure, which suits the high write volume of a global post firehose) and fetched by ID when rendering.

A CDN or edge cache layer handles read-heavy static assets (images, video thumbnails), while the feed service itself sits behind an API gateway with per-user rate limiting to prevent scraping.

Comparison Table: Fan-Out Strategies

FAQ

Q: What follower threshold should split push vs pull in the hybrid model? A: There’s no universal number, but interviewers want to see you reason about it: pick a threshold (commonly cited examples land between 10K-1M followers) where the write amplification of push starts to exceed acceptable infrastructure cost, and justify it with rough math (threshold × average post frequency = writes/sec you’re willing to absorb).

Q: How do you handle a user unfollowing someone under the push model? A: The precomputed feed doesn’t need immediate retroactive cleanup — stale posts naturally age out as the capped list rolls over. Some systems tag posts with the follow-relationship version to filter stale entries at read time if strict correctness is required.

Q: Should the feed be strongly consistent? A: No — nearly every production feed system accepts eventual consistency. A post appearing 1-3 seconds late in a follower’s feed is an acceptable tradeoff for the throughput and availability gains of asynchronous fan-out via a message queue (Kafka is standard for the write pipeline that triggers fan-out workers).

Feed design questions test exactly the kind of tradeoff reasoning — read/write asymmetry, caching layers, hybrid architecture — that shows up across dozens of other system design prompts. The 0-to-1 SWE Interview Playbook (https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20) walks through this feed design case study plus a repeatable framework for approaching any system design prompt in 2026 interview loops.