Durgesh Tiwari
Author
A News Feed System looks simple from the user's point of view.
You open an app and see posts from people, pages, groups, or topics you follow. You scroll, and more content appears.
Behind that simple experience, the system must answer difficult questions:
Which posts should this user see?
Should the feed be chronological or ranked?
How do we generate feeds for millions of users?
What happens when a celebrity with millions of followers posts?
Should feeds be precomputed or generated at read time?
How do we keep feed latency low?
How do we paginate a continuously changing feed?
How do we handle deleted, private, or blocked content?
These questions make News Feed System Design an important system design interview topic.
In this guide, we will build a scalable News Feed System step by step and understand fan-out, ranking, caching, pagination, sharding, reliability, and major architecture trade-offs.
A News Feed System selects, orders, and delivers content to a user.
The feed may contain:
Posts
Images and videos
Articles
Reposts
Group updates
Recommendations
Suggested content
Ads
For example:
Post from Alice
Post from Rahul
Post from Tech Group
Recommended Post
AdvertisementThe feed may be chronological, ranked, personalized, or a combination of these approaches.
Suppose Alice follows:
Bob
Priya
John
TechNewsTheir recent posts may become candidates for Alice's feed:
Bob → "Good morning!"
Priya → "New project launched."
John → "Traveling today."
TechNews → "New database release."At small scale, we can fetch these posts directly.
At large scale, feed generation becomes a distributed systems problem because the platform may have millions of posts, huge social graphs, extremely high read traffic, and creators with very different follower counts.
The News Feed System should support the core operations required to publish and consume feed content.
Create and delete posts
Follow users
View a personalized feed
Scroll through older feed items
Like and comment on posts
See reasonably fresh content
The main focus is feed generation and delivery.
A large News Feed System should prioritize:
Low Latency: Load the first feed page quickly.
High Availability: Feed requests should survive server failures.
Scalability: Support large user, post, and traffic growth.
Freshness: New content should appear reasonably quickly.
Fault Tolerance: Handle worker, queue, cache, and service failures.
High Read Throughput: Feed reads usually dominate writes.
Reasonable Consistency: Small delays are acceptable for many feed updates.
For social feeds, low latency and availability are usually more important than immediate consistency for every update.
Suppose the platform has:
500 million registered users
100 million daily active users
10 million posts per dayIf each active user opens the feed 10 times per day:
100 million × 10
= 1 billion feed requests/dayAverage feed request rate:
1,000,000,000 / 86,400
≈ 11,600 requests/secondPeak traffic may be several times higher.
Read traffic can therefore be much larger than post-creation traffic, so feed delivery must be heavily optimized for reads.
A simplified architecture is:
+------------------+
| Mobile / Web App |
+--------+---------+
|
v
+------------------+
| API Gateway |
+----+--------+----+
| |
+-------+ +-------+
| |
v v
+--------------+ +--------------+
| Post Service | | Feed Service |
+------+-------+ +------+-------+
| |
+------+-------+ +-----+------+
| | | |
v v v v
+----------+ +---------+ +----------+ +----------+
| Post DB | | Outbox | |Feed Cache| |Feed Store|
+----------+ +----+----+ +----------+ +----------+
|
v
+-------------+
|Event Broker |
+------+------+
|
v
+-------------+
| Fan-Out |
| Workers |
+------+------+
|
v
Feed StoreSupporting services include:
Social Graph Service
Ranking Service
Recommendation Service
Engagement Service
Media/Object Storage
CDNThe Post Service owns durable post creation, while fan-out happens asynchronously. The Feed Service retrieves candidates, filters and ranks them, hydrates post data, and returns the final feed.
The Post Service creates and retrieves posts.
A post record may contain:
post_id
author_id
content
media_id
created_at
visibility
statusExample:
post_id: post_9001
author_id: user_101
content: "Learning distributed systems."
created_at: ...The Post Store remains the durable source of truth for post data.
A basic creation API may be:
POST /posts
{
"content": "Started learning system design today."
}The authenticated user identity should normally come from the authentication context rather than trusting a client-supplied user_id.
The Social Graph Service stores relationships between users.
Alice follows Bob
Alice follows Priya
John follows AliceTwo important access patterns are:
Who does Alice follow?
Who follows Alice?At scale, we may maintain both directions:
following:{user_id}
followers:{user_id}The following list helps read-time feed generation, while the followers list is important for fan-out on write.
Suppose Bob follows:
Alice
John
PriyaHow should Bob's feed be generated?
There are two main strategies:
Fan-Out on Read
Fan-Out on WriteChoosing where to perform this work is the central architecture decision in News Feed System Design.
With fan-out on read, the feed is generated when the user requests it.
Bob Requests Feed
|
v
Find Bob's Followees
|
v
Fetch Recent Posts
|
v
Merge Candidates
|
v
Filter + Rank
|
v
Return FeedFor example:
Alice Posts
\
John Posts ----> Merge ----> Bob's Feed
/
Priya PostsThis keeps post creation cheap because we do not immediately copy a post reference into every follower's feed.
However, if Bob follows thousands of accounts, every feed request may require expensive retrieval and merging.
Advantages:
Low write amplification
Simple post creation
Useful for creators with huge follower counts
Disadvantages:
Expensive feed reads
Higher read latency
More merging and social-graph work
With fan-out on write, more work happens after a post is created.
Suppose Alice creates post_100 and has 1,000 followers.
Alice Publishes post_100
|
v
Find Followers
|
+---+---+---+
| | | |
v v v v
Bob John Priya RahulThe post ID is asynchronously inserted into follower feed stores.
Bob's precomputed feed may already contain:
post_100
post_91
post_89
post_80When Bob requests his feed, the system can read this precomputed list instead of rebuilding it from scratch.
Advantages:
Very fast feed reads
Simple feed retrieval
Good for read-heavy systems
Disadvantages:
High write amplification
Expensive for users with huge follower counts
Requires asynchronous workers and additional feed storage
Suppose a celebrity has:
100 million followersWith pure fan-out on write:
1 Post
|
v
100 Million Feed WritesOne post could create enormous pressure on queues, workers, caches, and feed storage.
This is the celebrity problem.
It shows why a single fan-out strategy is not ideal for every user.
A practical News Feed System can combine both approaches.
For normal users:
Fan-Out on WriteFor celebrities or very high-follower accounts:
Fan-Out on ReadFor example:
Alice
2,000 followers
→ Fan-Out on Write
Celebrity
80 million followers
→ Fan-Out on ReadWhen Bob requests his feed:
Precomputed Feed
|
+---- Normal-user posts
|
+---- Celebrity posts fetched at read time
|
v
Candidate Merge
|
v
Filter + Rank
|
v
Final FeedThis avoids massive celebrity fan-out while keeping most feed reads fast.
The threshold does not have to depend only on follower count. The system can also consider posting frequency, active-follower count, queue load, and storage cost.
Post creation should not wait for thousands or millions of follower-feed updates.
The write path can be asynchronous:
Post Service
|
v
Store Post + Outbox Event
|
v
Return SuccessThen:
Outbox Publisher
|
v
Event Broker
|
v
Fan-Out Workers
|
v
Feed StoreThe event broker provides:
Decoupling
Buffering
Retries
Independent worker scaling
Failure recovery
The user receives confirmation after the post has been durably stored, while feed distribution continues asynchronously.
The Feed Store should usually contain lightweight references instead of complete copies of posts.
A feed entry may contain:
user_id
post_id
score
created_atFor example:
Bob Feed
----------------
post_100
post_95
post_81
post_73The actual content remains in the Post Store.
Feed Store → post_id
Post Store → actual postThis avoids copying text, media metadata, author details, and engagement counters into millions of feeds.
The first page of a feed is frequently requested, so recent feed IDs can be stored in a distributed cache.
user_101 → [post_100, post_95, post_81, ...]Request flow:
Feed Request
|
v
Feed Cache
|
+---- HIT → Use Cached Candidates
|
+---- MISS → Feed StoreA system such as Redis can be used depending on scale and requirements.
Caching reduces feed-store load and read latency.
We usually do not need to store a user's entire historical feed forever.
Instead, keep a bounded recent window, such as:
Last 500 feed itemsor:
Recent N daysThe exact limit depends on product behavior.
Older content can be retrieved or generated through a separate path when the user scrolls far enough.
The simplest feed is reverse chronological:
Newest Post
Second Newest
Third Newest
...Conceptually:
score = created_atThis is simple and fresh but may not surface the most relevant content.
A ranked feed instead calculates a relevance score using signals such as:
Freshness
Relationship strength
Previous interactions
Engagement
Content relevance
Content quality
Negative feedback
Predicted engagementFor example, if Bob frequently interacts with Alice's posts, Alice's new post may receive a higher score.
Before ranking, the system needs candidate posts.
Candidates may come from:
Followed Accounts
Groups
Recommendations
Topics
Trending Content
AdvertisementsConceptually:
Following Posts ----\
Group Posts ---------\
Recommendations ------> Candidate Pool
Trending Posts -------/
Ads -----------------/A large system should not run its most expensive ranking model over every candidate.
Instead:
Thousands of Candidates
|
v
Filtering
|
v
Lightweight Ranking
|
v
Top Few Hundred
|
v
Advanced Ranking
|
v
Top ResultsThis balances ranking quality and latency.
Ranking can happen at different stages.
Approach | Advantage | Trade-Off |
|---|---|---|
Rank During Write | Faster reads | Scores can become stale |
Rank During Read | Fresher signals and personalization | More computation and latency |
Hybrid | Fast candidate retrieval with fresh reranking | More system complexity |
A practical design often precomputes candidate feeds and reranks a smaller candidate set at read time.
Posts may receive:
Likes
Comments
Shares
ViewsWe should not rewrite millions of feed entries whenever a like count changes.
Instead:
Feed Entry → post_id
Post/Engagement Service → current engagement dataEngagement data can be fetched or cached during feed hydration.
Like and view counts can usually be eventually consistent because a temporary difference such as 10,000 vs 10,001 does not require financial-level consistency.
Feeds should return small pages rather than thousands of posts at once.
First Request → 20 items
Second Request → Next 20
Third Request → Next 20Offset Pagination | Cursor Pagination |
|---|---|
Example: | Example: |
Simple to implement | Better for changing datasets |
Items can shift when new posts arrive | Continues from a stable position |
Can create duplicates or skipped items | More suitable for dynamic feeds |
A cursor may encode or reference:
last_score
last_timestamp
last_post_idFor ranked feeds, the cursor should correspond to the same deterministic ordering used by the query.
Two posts may have the same ranking score.
Post A → score 100
Post B → score 100Use a deterministic tie-breaker:
ORDER BY score DESC, post_id DESCor another stable unique key.
Stable ordering is important for reliable cursor pagination.
Suppose Bob is viewing:
A
B
C
DThen a new post X arrives.
Immediately inserting X into the middle of Bob's active scrolling session may make the feed jump.
A product may instead show new content when Bob:
Refreshesor:
Returns to the topFeed stability is partly a product decision, not only a backend decision.
Precomputed feeds can contain stale references, so final delivery must still enforce current rules.
For a deleted post:
Feed Contains post_100
|
v
Hydrate Post
|
v
Post = DELETED
|
v
SkipThe same principle applies to:
Privacy changes
Blocked users
Muted accounts
Hidden content
Policy restrictions
Background cleanup can eventually remove stale feed references, but current authorization and visibility checks must not depend only on old cached feed state.
Images and videos should normally be stored outside the main post database.
Client
|
v
Media Upload Service
|
v
Object Storage
|
v
CDN
|
v
UsersThe Post Service stores references such as:
media_id
object_key / media reference
metadataA CDN serves popular media closer to users and reduces load on the origin storage system.
A viral post may be requested millions of times.
Instead of repeatedly reading it from the primary database:
Feed Service
|
v
Post Cache
|
+---- HIT
|
+---- MISS → Post StoreCelebrities can also create hot keys for profiles, posts, follower lists, and engagement counters.
Possible techniques include:
Replication
Distributed caching
Local caches
Read replicas
Request distribution
Key splitting where appropriate
CDN for media
Hot-key handling becomes important when traffic is highly uneven.
With billions of posts, one database node may not be enough.
Possible partition keys include:
author_idor:
post_idFor example:
hash(author_id) → Post ShardAuthor-based partitioning makes author-history queries easier but may create hot partitions for unusually active authors.
Hashing by post ID can distribute writes more evenly but may make author-based queries more distributed.
The partition key should follow actual access patterns.
Feed data naturally belongs to a user, so a common partition key is:
user_idFor example:
hash(user_id) → Feed ShardThis keeps one user's recent feed entries together and makes feed retrieval efficient.
Very active users can still become hot partitions, so hot-user mitigation may be required at extreme scale.
The social graph needs efficient access in both directions:
following:{user_id}
followers:{user_id}At large scale, these adjacency lists can be partitioned.
Maintaining both directions avoids expensive reverse lookups but duplicates relationship data.
For very large follower lists, fan-out workers should read followers in pages or batches rather than loading the entire list into memory.
Suppose a creator has millions of followers and still qualifies for fan-out on write.
Do not process every follower in one operation.
Follower Batch 1 → 10,000 users
Follower Batch 2 → 10,000 users
Follower Batch 3 → 10,000 users
...Multiple workers can process batches in parallel.
This improves scalability and makes failed work easier to retry.
Suppose a worker processes users 1–10,000 and crashes halfway through.
The message may be retried.
Feed writes should therefore be idempotent.
Conceptually:
unique(user_id, post_id)or equivalent duplicate protection.
Then processing the same post/follower combination more than once does not create duplicate feed entries.
Fan-out work can flow through a durable queue:
Post Created
|
v
Message Queue
|
+---+---+---+
| | | |
v v v v
W1 W2 W3 W4Suppose workers can process:
1 million feed writes/secbut a traffic burst generates:
3 million feed writes/secThe queue buffers the temporary difference.
The system can also:
Autoscale workers
Apply rate controls
Delay lower-priority work
Reduce optional work
Monitor queue age and depth
This prevents downstream overload from becoming a cascading failure.
Under heavy load, slightly delayed feed updates are usually better than system instability.
Option A:
Instant feed updates
but unstable system
Option B:
Feed updates delayed slightly
but healthy systemFor most social feeds, Option B is preferable.
This is one reason asynchronous fan-out and eventual consistency work well.
When Bob opens the application:
Bob
|
v
API Gateway
|
v
Feed Service
|
+----> Feed Cache / Feed Store
|
+----> Celebrity Live Candidates
|
+----> Recommendations / Groups / Ads
|
v
Candidate Merge
|
v
Deduplication
|
v
Filtering
|
v
Ranking
|
v
Feed Mixing
|
v
Hydration
|
v
First Page + CursorThis is the core online read path.
The same post may arrive from multiple sources.
For example:
Follow Candidate
+
Recommendation CandidateDeduplicate candidates using:
post_idThen filter content the user should not see:
Deleted posts
Blocked users
Muted accounts
Private or inaccessible content
Hidden items
Policy-restricted content
Correct filtering is more important than immediately removing every stale reference from every cache.
Feed candidates may initially contain only:
post_id
scoreThe Feed Service then fetches the data required to render them:
Content
Author
Media
EngagementThis is often called hydration.
For 20 feed items, a poor design might make:
1 feed request
+ 20 post calls
+ 20 author callsInstead, batch retrieval:
GET posts [1..20]
GET users [author IDs]or use optimized internal batch APIs.
This reduces network overhead and latency.
Raw ranking is not always the final order.
Suppose the highest-ranked results contain five videos from the same creator.
The Feed Mixer can enforce product constraints such as:
Creator diversity
Content-type diversity
Topic variety
Ad spacing
Recommendation limits
For example:
Organic Candidates
\
→ Feed Mixer → Final Feed
/
Ad CandidatesMixing lets product rules modify the final ordering without replacing the ranking system.
Different data requires different consistency guarantees.
Stronger Correctness | Eventual Consistency Often Acceptable |
|---|---|
Post ownership | Feed fan-out |
Privacy authorization | Like counts |
Delete/visibility status | View counts |
Access control | Ranking features |
Follower counts |
Using the strongest consistency model for everything would add unnecessary latency and complexity.
Suppose post creation requires:
1. Store Post
2. Publish post.createdIf the post is committed but event publishing fails, the post exists while followers may never receive it.
This is a dual-write problem.
The Transactional Outbox Pattern can make post persistence and event intent atomic.
BEGIN TRANSACTION
INSERT Post
INSERT Outbox Event
COMMITThen:
Outbox Table
|
v
Outbox Publisher
|
v
Event Broker
|
v
Fan-Out WorkersIf broker publishing fails, the publisher retries.
Consumers should still be idempotent because the same event may be delivered more than once.
Feed caches can use TTLs because feed data changes frequently.
Feed Cache
|
MISS
|
v
Feed StoreWe do not need perfect invalidation for every feed event.
For highly active users, the system may selectively keep recent feeds warm in cache.
Pre-warming every user's feed would waste memory, so it should be used only when access patterns justify it.
A global platform may serve users from multiple regions.
US Region
Europe Region
Asia RegionMulti-region architecture introduces additional concerns:
Cross-region post/event propagation
Feed freshness
Duplicate events
Data locality
Failover
Consistency
If one region fails, traffic may be routed to another healthy region.
Users might temporarily see slightly stale feeds or higher latency, which can be preferable to complete downtime.
Multi-region design should be introduced only after the single-region architecture is clear.
Important metrics include:
Feed request latency
Feed error rate
Feed cache hit rate
Candidate-generation latency
Ranking latency
Hydration latency
Fan-out queue depth
Oldest fan-out event age
Fan-out throughput
Failed/retried fan-out jobs
Candidate count
Cache memory usage
Celebrity and viral-content traffic should also be monitored because they can create unusual load patterns.
Suppose Alice creates a post.
Alice
|
v
POST /posts
|
v
Post Service
|
v
Authenticate + Validate
|
v
Database Transaction
|
+---- Store Post
|
+---- Store Outbox Event
|
v
Commit
|
v
Return SuccessAsynchronously:
Outbox Publisher
|
v
post.created
|
v
Event Broker
|
v
Fan-Out Service
|
v
Choose Fan-Out Strategy
|
+---- Normal User → Fan-Out on Write
|
+---- Celebrity → Keep for Read-Time MergeFor fan-out on write:
Follower Batches
|
v
Fan-Out Workers
|
v
Idempotent Feed Writes
|
v
Feed Store / CachePost creation remains fast because follower distribution is not part of the synchronous request path.
When Bob opens the application:
GET /feed
|
v
Feed Service
|
v
Retrieve Precomputed Candidates
|
+---- Feed Cache
|
+---- Feed Store
|
v
Add Celebrity / Live Candidates
|
v
Add Recommendations / Groups / Ads
|
v
Deduplicate
|
v
Apply Privacy + Visibility Filters
|
v
Rank Candidates
|
v
Mix Results
|
v
Batch Hydration
|
v
Return First Page + CursorThis combines precomputed data with read-time candidates while keeping the online path efficient.
+------------------+
| Mobile / Web App |
+--------+---------+
|
v
+------------------+
| API Gateway |
+----+--------+----+
| |
+---------+ +---------+
| |
v v
+-------------+ +-------------+
|Post Service | |Feed Service |
+------+------+ +------+------+
| |
+------+-----+ +----------+----------+
| | | | |
v v v v v
+---------+ +--------+ Feed Cache Feed Store Candidate
|Post Store| | Outbox | Sources
+---------+ +---+----+ |
| |
v |
+-------------+ |
|Event Broker | |
+------+------+ |
| |
v |
+-------------+ |
| Fan-Out | |
| Workers | |
+------+------+ |
| |
v |
Feed Store |
|
+---------------------------------+
|
v
+------------------+
| Candidate Merge |
+--------+---------+
|
v
+------------------+
| Filter + Rank |
+--------+---------+
|
v
+------------------+
| Feed Mixer |
+--------+---------+
|
v
+------------------+
| Hydration |
+--------+---------+
|
v
Final FeedSupporting systems include:
Social Graph
Recommendation Service
Engagement Service
Post Cache
Media/Object Storage
CDN
ObservabilityA News Feed System balances read latency, write amplification, freshness, relevance, storage, and availability.
Fan-Out on Write vs Read: Write-time fan-out gives fast reads but creates write amplification; read-time fan-out reduces writes but makes reads more expensive.
Precomputation vs Real-Time Generation: Precomputed candidates reduce latency but consume storage and can become stale.
Chronological vs Ranked Feed: Chronological feeds are simple and fresh; ranked feeds improve relevance but require more computation.
Ranking Freshness vs Latency: Read-time reranking uses fresher signals but adds request-time work.
Cache vs Freshness: Caching reduces latency but can temporarily serve stale candidate lists.
Storage vs Compute: Precomputing feeds spends more storage to reduce read-time computation.
Freshness vs Stability: Slightly delayed feed updates may be better than overloading the system.
A hybrid architecture is usually the practical answer rather than choosing one extreme everywhere.
HLD focuses on distributed architecture and scale, while LLD focuses on component-level software design.
Feature | HLD | LLD |
|---|---|---|
Focus | Architecture and scalability | Classes, interfaces, and algorithms |
Main Topics | Fan-out, feed store, caching, ranking, queues, sharding | FeedItem, services, strategies, repositories |
Components | Post Service, Feed Service, Social Graph, Ranking Service | Post, FeedItem, FeedService, FanOutStrategy |
Main Question | How does the News Feed work and scale? | How is each component implemented? |
Possible LLD abstractions:
FanOutStrategy
|
+-- FanOutOnWrite
|
+-- FanOutOnRead
|
+-- HybridFanOutand:
RankingStrategy
|
+-- ChronologicalRanking
|
+-- EngagementRanking
|
+-- PersonalizedRankingA News Feed System should become more complex only when traffic and product requirements justify it.
Start with:
Users
|
v
Application Server
|
v
SQL DatabaseAt feed time:
Find Followed Users
+
Query Recent PostsThis can be enough for a small product.
Add:
Feed Cache
Post Cache
Cursor PaginationIntroduce:
Fan-Out on Write
Feed Store
Message Queue
Fan-Out WorkersAdd:
Hybrid Fan-Out
Fan-Out on Read for Large AccountsAdd:
Candidate Generation
Ranking Service
Recommendation Service
Feed MixerAdd when required:
Multi-Region Infrastructure
Advanced Sharding
Cross-Region Events
Large-Scale Feature Pipelines
Sophisticated CachingDo not begin with internet-scale complexity when a simpler architecture satisfies the requirements.
Store posts separately, maintain follow relationships, and use a Feed Service to deliver relevant content.
For normal users, asynchronously fan post references out to follower feed stores. For users with very large follower counts, retrieve their recent posts at read time.
Then add caching, filtering, ranking, cursor pagination, queues, and sharding as scale grows.
Fan-out means distributing a new post to users who should receive it.
For example, if Alice has 1,000 followers, her post may be added to 1,000 precomputed follower feeds.
Fan-out on write adds a post reference to follower feeds after the post is published.
It makes feed reads fast but creates write amplification.
Fan-out on read retrieves posts from followed accounts when the user requests the feed.
It reduces write amplification but makes feed reads more expensive.
Use a hybrid strategy.
Avoid writing one celebrity post into millions of follower feeds. Fetch recent celebrity posts at read time and merge them with the user's precomputed candidates.
A user with 100 million followers could generate roughly 100 million feed-entry writes for one post.
That can overload workers, queues, caches, and storage.
Every feed request would need to retrieve and merge posts from followed accounts.
For users following thousands of accounts, this creates high read latency and backend load.
Generate candidates and score them using signals such as:
Freshness
Relationship strength
Engagement
Content relevance
Past interactions
Negative feedbackFor large candidate sets, use multi-stage ranking.
Store lightweight feed entries such as:
user_id
post_id
score
timestampKeep full post content in the Post Store.
Use cursor-based pagination with a cursor based on the feed's stable ordering, such as:
score
timestamp
post_idThis works better than offsets when the feed changes continuously.
Deduplicate candidates using post_id.
Fan-out writes should also be idempotent so retries cannot create duplicate (user_id, post_id) entries.
Retry the message or follower batch.
Because feed writes are idempotent, reprocessing already completed followers remains safe.
Mark the post deleted in the source-of-truth Post Store.
During hydration or filtering, skip deleted content. Background cleanup can later remove stale feed references.
Apply current authorization, privacy, and relationship filters before returning the final feed.
Cached candidate IDs must not bypass current visibility rules.
The queue decouples post creation from fan-out.
It buffers bursts, supports retries, and lets fan-out workers scale independently.
Cache hot post data, serve media through a CDN, distribute reads, and avoid repeatedly querying the primary database.
Engagement counters can be updated asynchronously when exact immediate values are unnecessary.
It depends on the access pattern.
Relational storage can work for structured user and post metadata, while large feed timelines may use distributed key-value or wide-column storage.
The social graph may use another representation optimized for adjacency-list access.
Partition feed data by user_id.
hash(user_id) → Feed ShardCache or replicate hot data when required.
Use asynchronous fan-out for normal users and read-time merging for live or non-precomputed candidates.
Small propagation delays are usually acceptable for social feeds.
Cache recent feed IDs for active users and cache hot posts separately.
Use TTLs and fall back to durable Feed Store data on cache misses.
New posts can shift offset positions while the user scrolls, causing skipped or duplicate results.
A cursor tied to stable ordering is better for dynamic feeds.
Store engagement separately from feed entries.
Fetch or cache current engagement values during hydration rather than rewriting every user's feed whenever a counter changes.
Use multiple stateless service instances, replicated storage where required, distributed caches, durable queues, retries, load balancing, and graceful degradation.
If ranking is temporarily unavailable, the system may return a simpler feed rather than failing the entire request.
Graceful degradation means returning a simpler but useful feed when an optional component fails.
For example:
Ranking Service Unavailable
|
v
Fallback Candidate Ordering
|
v
Return FeedThe exact fallback depends on what candidate data is still available.
The central trade-off is:
Fan-Out on Write
vs
Fan-Out on ReadA hybrid strategy is often the practical solution because normal users and celebrity accounts create very different traffic patterns.