News Feed System Lifecycle Visualization
Walk through a scale-out news feed lifecycle from publishing and moderation to fan-out, timeline cache reads, hydration, ranking, and recovery.
Continue with the guided workspace
Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.
Mental Model
A scale-out News Feed system must balance low read latency (sub-100ms) with high write volumes. Standard architectures utilize a hybrid fan-out model that separates normal users from high-following celebrity users, pre-computing timelines in memory caches while retrieving and merging celebrity activity on demand.
The paired simulator makes the push-versus-pull tradeoff observable through cache state, celebrity behavior, and request latency.
Components and Why They Exist
Client Nodes
Represents active end-users who publish posts (writes) or fetch their home feed timelines (reads). Generates incoming traffic workload and measures client-side request latencies. In the demo, observe request particles flowing from the client: writes (orange/purple) and reads (blue).
Load Balancer & Web Server
Serves as the gateway to distribute requests across the application layer and protect internal services. Receives incoming client HTTP traffic, applies rate-limiting rules, and routes writes to the Post Service and reads to the Feed Service. In the demo, watch requests route through the Load Balancer to the respective downstream services.
Post Service
Manages the initial write pipeline when a user publishes content. Orchestrates pre-write checks (such as content moderation), persists the source-of-truth post to the Metadata DB, and sends a task to the Fan-out Service. In the demo, watch the post service activate during publishing, communicating with moderation and Metadata DB.
Fan-out Service
Offloads the heavy CPU and network work of updating follower timelines from the synchronous request path. Pulls the followers of a normal author and writes the new post ID into each follower’s pre-computed cache timeline. In the demo, watch the Fan-out queue length metric and updates sent to the Feed Cache.
Feed Cache (Redis)
Provides ultra-fast, in-memory retrieval of chronological lists of post IDs, shielding databases from feed reads. Stores pre-computed feed timelines (consisting of post IDs) for active users. In the demo, observe cache hit ratios. Note the read path querying the cache.
Metadata Database (Metadata DB)
Serves as the relational or document-based persistent storage for complete user profiles and post payloads. Saves new posts, queries posts by celebrity authors dynamically, and fetches actual post details during feed hydration. In the demo, watch database operations commit new posts and handle hydration queries.
Feed Service
Handles user read requests to compile their home feed. Fetches the pre-computed timeline from the Feed Cache, queries the Metadata DB for celebrity posts, merges them, fetches details (hydration), and ranks the results. In the demo, observe read latency metrics; watch the feed service aggregate data from cache and database.
Edge Cases and Misconceptions
Fan-out Write Amplification (The Celebrity Pitfall)
A common misconception is that a single fan-out on write (push) model works for all users. If a celebrity with 50 million followers publishes a post, pushing that post ID to 50 million feed caches instantly overloads memory queues and Redis write channels. A hybrid model is required: celebrity posts bypass fan-out entirely, writing only to the database, and are dynamically pulled and merged by the Feed Service during a follower’s read request.
Cache Stampede and Database Overload
When an in-memory Feed Cache fails or entries expire simultaneously, incoming read requests fall back to querying the database directly. This creates a cache stampede (or thundering herd) where the Metadata DB is bombarded with complex timeline compilation queries, leading to server timeouts and cascading failures.
Hydration Overhead vs. Caching complete Posts
To conserve expensive RAM, feed caches typically store only a list of 64-bit post IDs rather than complete post bodies and media objects. The tradeoff is that the read path must perform a “hydration” step—querying the Metadata DB or a secondary document cache to fetch the actual post content before returning it to the user. This makes database read IOPS a key scalability bottleneck.\n
Common Questions
What is the difference between Push and Pull models in a News Feed?
The Push (Fan-out on write) model inserts posts into all follower caches when a post is created. The Pull (Fan-out on read) model fetches posts from authors at the moment the follower requests their feed. A hybrid model pushes normal user posts to follower caches but pulls celebrity posts on demand to avoid write amplification.
How are celebrity posts handled to prevent write amplification?
Celebrities have large follower counts. Pushing to all their caches creates massive write amplification. Instead, celebrity posts bypass the Fan-out Service and write only to the Metadata DB. When a follower requests their feed, the Feed Service queries the DB to pull celebrity posts and merges them with the cached timeline.
Why is Feed Cache critical in this architecture?
Querying the database to fetch and rank posts for every user request causes huge read latency and DB overload. Caching the pre-computed feed timelines in memory (e.g. Redis Clusters) allows sub-15ms reads.
What is post metadata hydration?
To save cache memory, feed cache stores only Post IDs rather than complete post objects. When retrieving the feed, the Feed Service retrieves these IDs from the cache, fetches details (user profiles, post text, media links) from the Metadata DB, and merges them to form the final response.
How is feed generation latency optimized?
Pre-computing the feed timelines (Push/Fan-out on write) shifts work from read-time to write-time, enabling fast sub-15ms feeds. For celebrities, bypassing push avoids cache lockups, and using efficient DB queries (e.g. index on authorId and timestamp) ensures pulling celebrity posts on read-time is quick.
What is write amplification and why does it occur?
Write amplification occurs when a single write request triggers multiple subsequent writes. For a news feed system, if a user has 10 million followers, publishing one post means the system must write 10 million timeline cache entries. A hybrid model selectively disables push for celebrities to keep write QPS manageable.
How does feed ranking affect latency?
Moving from chronological sorting to engagement scoring requires executing ranking models (which calculate scores based on user behavior, post features, and affinity) for every post on the read path. This increases the CPU overhead of the Feed Service, causing feed retrieval latency to rise from ~15ms to ~45ms.