VetoraFeed Ranking — Naive (Chronological + Heuristic)
The simplest possible news feed ranking architecture: a single FeedService backed by PostgreSQL. Posts from followed users are retrieved and sorted at query time using a heuristic score (recency + likes + affinity). No ML, no candidate pre-computation, no engagement feedback. Demonstrates why query-time ranking degrades at scale and why pre-computed candidates with ML scoring become essential.
Problem Statement
Feed ranking is one of the most frequently asked system design interview questions because it lies at the heart of every major social platform — Facebook, Instagram, LinkedIn, Twitter, TikTok, and Reddit all depend on algorithms that decide which content to show each user and in what order. Companies like Meta, LinkedIn, Reddit, and TikTok ask variants of this question because it directly maps to their core product engineering challenges: candidate retrieval, relevance scoring, engagement optimization, and content diversity.
The naive approach uses the simplest possible architecture: a single FeedService backed by PostgreSQL. When a user opens their feed, FeedService retrieves the user's follow list from FollowCache (Redis), then queries PostDB for all recent posts from followed users: SELECT p.*, (w1 * recency_score(p.created_at) + w2 * p.like_count + w3 * affinity_score(viewer_id, p.author_id)) AS score FROM posts p WHERE p.author_id IN (followed_ids) AND p.created_at > NOW() - interval '7 days' ORDER BY score DESC LIMIT 50. This query scans every post from every followed user in the last 7 days, computes a heuristic score for each row, sorts the entire result set, and returns the top 50. It is an O(N log N) sort per request where N is the total candidate count.
At 100 follows with 10 posts/day each, N is approximately 7,000 rows — manageable in 80-100ms. At 500 follows, N grows to 35,000 rows and query latency reaches 400-600ms. At 1,000 follows (common for power users on platforms like Twitter), N exceeds 70,000 rows and latency pushes past 1 second, violating the 500ms p99 SLO. The fundamental problem is that ranking cost grows linearly with the user's social graph size and the posting frequency of the people they follow.
The heuristic score itself is a hand-tuned weighted formula: w1 controls recency decay (exponential decay from publish time, typically half-life of 6 hours), w2 controls popularity signal (raw like count, normalized), and w3 controls author affinity (a static score pre-computed from past interaction history — how often the viewer likes or comments on this author's posts). These weights are manually tuned by product managers and engineers — there is no learning from user behavior, no personalization beyond the static affinity score, and no adaptation to changing interests.
The architecture has no engagement feedback loop. When a user clicks, likes, or spends time reading a post, that signal is not captured or fed back into ranking. The next feed request uses the same static heuristic weights. A user who consistently ignores sports posts but engages deeply with tech posts will continue seeing sports posts ranked by the same formula. This lack of personalization is the primary quality gap compared to ML-based ranking systems.
This template exists to make the query-time ranking bottleneck visible and measurable. Run the simulation at increasing follow counts and watch PostgreSQL query latency grow linearly while the heuristic score produces the same generic ranking for all users. The comparison with the V1 Multi-Stage ML Pipeline variant quantifies the improvement: pre-computed candidates from Redis (2ms retrieval) plus a lightweight ranker (20ms scoring) replace the 400ms+ database query — a 10x latency reduction with significantly better ranking quality from ML-based engagement prediction.
Interviewers expect candidates to identify the O(N log N) query-time sort as the scalability bottleneck, propose candidate pre-computation (fanout-on-write) as the solution, discuss the limitations of heuristic scoring versus ML-based ranking, and reason about the transition from pull-based (query on demand) to push-based (pre-compute and cache) feed generation.
Architecture Overview
The naive feed ranking system is a five-component architecture: Feed Client, Feed Load Balancer, Feed Service, Post Database (PostgreSQL), and Follow Cache (Redis). There is no ML model, no candidate pre-computation pipeline, no engagement stream, and no separation between feed retrieval and ranking — everything happens in a single database query.
All traffic arrives at the Feed Load Balancer (AWS ALB), which distributes requests across 8 FeedService pods using round-robin. The Load Balancer adds approximately 1.5ms of routing latency and can handle up to 120K RPS — well above the system's actual limits, which are constrained by the database. The Load Balancer is never the bottleneck; PostDB is.
FeedService handles three types of requests. Feed reads (80% of traffic): FeedService retrieves the user's follow list from FollowCache (Redis, 85% hit rate, 1.5ms), then queries PostDB with the heuristic scoring formula. The query JOINs the posts table with the follow list, computes scores, sorts, and returns the top 50. This is the hot path — 80K RPS at peak, each requiring a database sort over thousands of rows. Feed refresh (10% of traffic): identical to feed reads with no optimization — pull-to-refresh triggers the same full query. Post writes (10% of traffic): new posts are inserted into PostDB with no fanout, no notification, and no cache invalidation.
PostgreSQL stores three tables: posts (content with engagement counters), follows (follow relationships with static affinity scores), and users (profile metadata). A single primary instance with no read replicas handles all reads and writes. The feed query is the most expensive operation: it scans the posts table filtered by author_id IN (followed_ids) with a 7-day time window, computes a heuristic score per row using PostgreSQL functions, sorts by score descending, and returns the top 50. The query planner uses a composite index on (author_id, created_at) for the range scan, but the ORDER BY on a computed column forces a full sort of all matching rows.
FollowCache (Redis) stores follow lists per user — a set of 100-500 followee IDs cached with a 5-minute TTL. This eliminates repeated follow-table queries (one per feed request) but is explicitly not used for feed result caching. Feed results change every time a followed user posts or receives engagement, making cache invalidation impractically complex for the naive approach.
The system has no async pipeline, no event stream, no background workers, and no pre-computation. Every feed request pays the full ranking cost at query time. This architectural simplicity is the naive approach's strength (easy to understand, deploy, and debug) and its fatal weakness (query latency grows linearly with follow count, and there is no path to horizontal scaling of the ranking computation).
Architecture Preview
Request Flow — Query-Time Heuristic Feed Ranking
This sequence diagram traces the two primary flows: feed read (with heuristic ranking) and post write. The critical insight is the query-time sort — PostgreSQL must compute the heuristic score for every candidate row, sort the full result set, and return the top 50. At high follow counts, this scan-sort operation dominates request latency and becomes the system bottleneck.
The second insight is the lack of feedback: user engagement (clicks, likes, dwell time) is never captured or fed back into the ranking formula. The same 3 weights produce the same ranking regardless of individual user behavior.
Step-by-Step Walkthrough
- 1Feed client sends GET /feed. FeedService first checks FollowCache (Redis) for the user's follow list. 85% hit rate with 1.5ms latency. On miss, falls back to PostDB (~15ms) and populates the cache
- 2FeedService executes the main feed query on PostDB: SELECT with heuristic scoring formula, WHERE author_id IN (followed user IDs) filtered to last 7 days, ORDER BY computed score DESC, LIMIT 50. PostgreSQL scans all matching rows, computes 3 function calls per row, sorts the full result set, returns top 50
- 3At 100 follows with 10 posts/day, the query scans ~7,000 rows in ~100ms. At 500 follows, ~35,000 rows in ~500ms. At 1,000 follows, ~70,000 rows in 1s+. The sort cost grows with O(N log N)
- 4Post writes are simple INSERTs with no fanout or notification. The new post becomes visible to followers on their next feed request — no push mechanism, no cache invalidation
Pseudocode
// FEED READ — query-time heuristic ranking
async function getFeed(user_id, cursor):
// Step 1: Get follow list (Redis cache with DB fallback)
follow_ids = await redis.get("follows:" + user_id)
if not follow_ids:
follow_ids = await db.execute(
"SELECT followee_id FROM follows WHERE follower_id = $1",
[user_id]
)
await redis.set("follows:" + user_id, follow_ids, ttl=300)
// Step 2: Query posts with heuristic scoring (THE BOTTLENECK)
feed = await db.execute("""
SELECT p.post_id, p.content, p.author_id, p.like_count, p.created_at,
(0.4 * recency_score(p.created_at)
+ 0.35 * normalize(p.like_count)
+ 0.25 * f.affinity_score) AS score
FROM posts p
JOIN follows f ON f.followee_id = p.author_id AND f.follower_id = $1
WHERE p.created_at > NOW() - INTERVAL '7 days'
ORDER BY score DESC
LIMIT 50 OFFSET $2
""", [user_id, cursor])
// O(N log N) sort: 500 follows x 10 posts/day x 7 days = 35K rows = ~500ms
return feedDatabase Schema (ER Diagram)
The schema reflects the naive approach's single-database design. The posts table carries the ranking workload: every feed request scans thousands of rows from this table, computes a heuristic score per row, and sorts the full result set. The follows table provides the social graph for the IN-clause filter. Both tables share the same PostgreSQL instance.
The critical access pattern is the feed query: a range scan on the (author_id, created_at) index filtered by the viewer's follow list, with a computed ORDER BY that forces a full sort. The index helps with filtering but not with sorting by the heuristic score.
Key Design Decisions
Query-Time Heuristic Sorting
Choice
SELECT ... ORDER BY (w1*recency + w2*likes + w3*affinity) DESC LIMIT 50 on every feed request
Rationale
Computing the feed ranking at query time eliminates all pre-computation infrastructure: no fanout pipeline, no candidate cache, no worker fleet. One SQL query produces the feed. The cost is that every request pays the full O(N log N) sort cost, which grows with the number of followed users and their posting frequency. At 500+ follows, query latency exceeds 500ms. Pre-computed candidates with cached ranking (V1 approach) reduce this to 2ms retrieval + 20ms scoring — a 10x improvement.
Hand-Tuned Heuristic Weights
Choice
score = w1*recency + w2*likes + w3*affinity with manually set weights
Rationale
A weighted formula with 3 parameters is trivially simple to implement, debug, and explain to stakeholders. No training data, no model infrastructure, no cold-start problem. The quality ceiling is low — the same 3 weights apply to all users regardless of their unique preferences. ML-based ranking (V1) learns per-user preferences from engagement data and predicts engagement probability with 200+ features, dramatically improving relevance at the cost of model training and serving infrastructure.
Redis for Follow Lists Only
Choice
Cache follow lists in Redis but not feed results
Rationale
Follow lists change infrequently (follows/unfollows are rare) and are small (~4KB per user). Caching them with a 5-minute TTL eliminates one database query per feed request. Feed results, however, depend on all recent posts from all followed users plus their engagement counts — any new post or like changes the ranking. Caching feed results would require invalidation on every post and engagement event across all users, which is more complex than simply recomputing the feed each time.
Single PostgreSQL Instance
Choice
One database for posts, follows, and users with no read replicas
Rationale
A single database eliminates replication lag concerns and provides strong consistency. The feed query always sees the latest posts and engagement counts. The cost is that all 100K RPS at peak competes for one connection pool and one set of I/O resources. Adding read replicas would offload status queries but the heuristic ranking query needs the freshest data (latest like counts), making replicas with replication lag problematic for ranking accuracy.
No Engagement Feedback
Choice
User interactions (clicks, likes, dwell time) are not fed back into ranking
Rationale
An engagement feedback loop requires an event stream (Kafka), a feature update pipeline (workers), and a feature store — three additional components. The naive approach avoids this complexity entirely. The cost is zero personalization adaptation: the ranking formula does not learn from user behavior. A user who always ignores sports content and engages with tech content sees the same generic ranking on every visit. The V1 variant closes this loop via EngagementStream and FeatureWorker.
Scale & Performance
Target RPS
~100K peak (limited by PostgreSQL sort capacity at high follow counts)
Latency (p99)
80-200ms at 100 follows, 400-600ms at 500 follows, 1s+ at 1000 follows
Storage
~200 GB/year at moderate traffic (10M users, 5M posts/day)
Availability
~99% (single instance, no redundancy)
Time & Space Complexity
| Operation | Time | Space | Notes |
|---|---|---|---|
| Feed ranking (query-time sort) | O(N log N) — sort all candidate posts by heuristic score | O(N) — materialize all scored rows for sorting | N = posts from followed users in the last 7 days. At 500 follows with 10 posts/day each, N = 35,000 rows. PostgreSQL sorts in memory if work_mem is sufficient, otherwise spills to disk (orders of magnitude slower). This is the primary bottleneck. |
| Follow list lookup (FollowCache) | O(1) — Redis SET lookup by user_id | O(K) — K = number of follows (100-500) | 1.5ms on cache hit, 4ms on cache miss (falls back to PostgreSQL). Not a bottleneck — 85% hit rate and sub-5ms latency. |
| Post insertion (new post) | O(log N) — B-tree index insertion on (author_id, created_at) | O(1) — single row insert | Fast (~20ms) and not a bottleneck. No fanout, no cache invalidation, no event publication. The post becomes visible on the next feed request from any follower. |
Database Schema (HLD)
All user posts with engagement counters. The hottest table in the system — read on every feed request via a range scan on (author_id, created_at) with a 7-day window. Engagement counters (like_count, share_count) are updated on every interaction, affecting the heuristic ranking score.
Indexes: PK on post_id, idx_posts_author_time ON (author_id, created_at DESC), idx_posts_created ON (created_at DESC)
The composite index on (author_id, created_at DESC) is the primary access path for the feed query. PostgreSQL uses this index for the WHERE author_id IN (...) AND created_at > NOW() - '7 days' predicate, but the ORDER BY on the computed heuristic score forces a full sort of all matching rows — the index cannot help with sorting by a function of multiple columns.
Follow relationships with a pre-computed static affinity score. Read on every feed request (via FollowCache) to construct the IN-clause for the feed query. The affinity_score column is recalculated nightly by a batch job based on historical interaction rates.
Indexes: PK on id, idx_follows_follower ON (follower_id), UNIQUE ON (follower_id, followee_id)
Typically 100-500 rows per user. The full follow list is cached in Redis (FollowCache) with a 5-minute TTL. Cache hit rate is 85% since active users request feeds frequently. The affinity_score column is the only personalization signal in the naive approach — it is static, updated nightly, and does not adapt to real-time behavior changes.
User profile records. Read during feed assembly to display author metadata (name, avatar). Small table, fully cached in PostgreSQL buffer pool. Not a performance concern.
Indexes: PK on user_id, UNIQUE on username
Small table (~100K-10M rows depending on platform size). Fully cached in buffer pool after warmup. Read latency <1ms for cached rows.
What-If Scenarios
Power user follows 2,000 accounts (e.g., journalists, social media managers)
Impact
The feed query scans 2000 x 10 posts/day x 7 days = 140,000 rows per request. At this volume, PostgreSQL sort latency exceeds 2 seconds. The user experiences severe feed load times. Other users' queries compete for the same database resources, causing cascading latency degradation.
Mitigation
Cap the follow count or implement tiered query strategies (e.g., only scan the top 500 most-interacted-with follows at query time). Long-term: pre-compute candidate sets (V1 approach) so the follow count does not affect query-time latency.
Viral post receives 100K likes in 1 hour
Impact
The like_count column on the viral post is updated 100K times in 1 hour (~28 UPDATEs/sec on a single row). Each UPDATE acquires a row-level lock. The heuristic ranking uses like_count, so the viral post's score changes on every like — but since feeds are not cached, every feed request sees the latest count. The UPDATE contention is mild at 28/sec but creates write amplification on the posts table index.
Mitigation
Batch engagement counter updates: buffer likes in Redis and flush to PostgreSQL every 5 seconds (reducing 28 UPDATEs/sec to 1 UPDATE/5sec). The V1 variant handles this via EngagementStream with FeatureWorker batching.
Database failure (single point of failure)
Impact
Total system outage — no feed reads, no post writes, no follow list fallback (FollowCache misses cannot be resolved). Every user sees an error. Revenue loss is proportional to downtime x active user count.
Mitigation
Add RDS Multi-AZ for automated failover (30-60 seconds recovery). Implement a read-only degraded mode that serves cached follow lists from Redis with a static 'latest posts' fallback. Long-term: separate read and write paths with read replicas.
Failure Modes & Resilience
| Component | Failure | Impact | Mitigation |
|---|---|---|---|
| PostDB (PostgreSQL) | Connection pool exhaustion from concurrent feed queries | All feed reads fail with connection timeout errors. Post writes also fail since they share the same connection pool. Users see empty feeds and cannot create new posts. | Connection pooling via PgBouncer (transaction mode). Increase max_connections as a stopgap. Long-term: separate read path (feed queries) from write path (post inserts) with read replicas. |
| FeedService | Thread starvation from slow database queries blocking all threads | If feed queries take 1s+ (power users with many follows), all 800 threads (8 pods x 100 threads) can be occupied by slow requests. Fast requests (post writes, small-follow-count feeds) queue behind them. Cascading failure as clients retry timed-out requests. | Set query timeouts on feed queries (500ms max). Separate thread pools for feed reads vs post writes (bulkhead pattern). The V1 variant solves this structurally by replacing the database query with a Redis lookup (2ms). |
| FollowCache (Redis) | Cache unavailability | Follow list lookups fall back to PostgreSQL, adding 15-20ms per request and increasing database load by 15% (the 85% cache hit rate drops to 0%). Degraded performance but not a total outage — the system continues to function with higher latency. | Redis Cluster with automatic failover. Set maxmemory-policy to allkeys-lru. Implement graceful degradation to database reads on cache miss. |
Scaling Strategy
Vertical scaling only for PostgreSQL (upgrade instance size). Horizontal scaling for FeedService via pod count increase (8 -> 16 -> 32 pods). Auto-scaling trigger: CPU utilization > 70% for 3 consecutive minutes. The ceiling is approximately 10K DAU per PostgreSQL instance for users with 500+ follows, regardless of FeedService pod count, because the database query-time sort is the bottleneck. Beyond this ceiling, architectural changes are required: pre-computed candidates in Redis (V1) or two-tower retrieval with online learning (V2).
Monitoring & Alerting
Key metrics to monitor: (1) Feed query latency by follow-count bucket (p50, p99) — the primary performance indicator. Alert at p99 > 400ms for 100-follow users, critical at p99 > 800ms. (2) PostgreSQL active connections — alert at 70% of max_connections. (3) FollowCache hit rate — should be approximately 85%. Drop below 70% indicates TTL misconfiguration or traffic pattern change. (4) Post write throughput — should be approximately 10K/sec at peak. (5) Feed query row scan count — monitor the number of rows scanned per feed query; alert if median exceeds 50K (indicates power users degrading the shared database). Dashboard: Grafana with panels for feed latency histogram bucketed by follow count, database connection pool usage, cache hit rate over time, and post write throughput.
Cost Analysis
At moderate scale (1M DAU): PostgreSQL db.r7g.xlarge (~$350/month), Redis cache.r7g.large (~$200/month), ECS Fargate 8 pods (~$550/month), ALB (~$30/month). Total: ~$1,130/month. This is the cheapest variant but breaks down at high follow counts (500+) where query latency exceeds SLO. The V1 Multi-Stage ML variant at the same scale costs approximately $3,500/month (adding Redis candidate cache, Kafka, and ML workers) but handles 10x the query complexity with 5x lower latency — the per-user cost increases from $0.0011/user to $0.0035/user but delivers dramatically better feed quality.
Security Considerations
Authentication: JWT tokens validated on every request at FeedLB (~3ms overhead). Authorization: feed queries are scoped to the viewer's follow list — users cannot view posts from private accounts they do not follow. Rate limiting: per-user request limiting to prevent scraping (max 60 feed requests/minute). Data privacy: post content is visible only to followers of the author (for private accounts) or to all users (for public accounts). No PII is exposed in feed responses beyond public profile information (username, avatar).
Deployment Strategy
Rolling deployment for FeedService — replace one pod at a time while the ALB routes traffic to remaining pods. Database migrations run during low-traffic windows (2-4 AM local time). Redis cache warming happens naturally after deployment since active users trigger cache population on their first feed request. Zero-downtime deployment achievable for service code changes but not for schema migrations that modify indexed columns on the posts table.
Real-World Examples
- •Twitter's original chronological timeline (2006-2016) used a similar query-time approach before introducing algorithmic ranking in 2016
- •Early Facebook News Feed (2006-2009) used EdgeRank, a hand-tuned heuristic with affinity, weight, and time-decay — conceptually similar to this naive approach
- •Mastodon and other ActivityPub-based platforms still use chronological feeds as a philosophical choice, accepting the scalability limitations
- •Reddit's 'hot' ranking formula (upvotes, downvotes, time) is a heuristic similar to this approach, though Reddit additionally sorts by subreddit
Solution Comparison
| Variant | Tier | Latency | Throughput | Cost | Complexity | Reliability |
|---|---|---|---|---|---|---|
| V0: Naive (Chronological + Heuristic) | T1 | 80-200ms at 100 follows, 500ms+ at 500 follows | ~100K RPS (DB-limited) | $1,130/month | Low | 99% (single DB) |
| V1: Multi-Stage ML Pipeline | T2 | ~80ms (2ms cache + 20ms light rank + 50ms heavy rank) | 100K RPS | $3,500/month | Medium | 99.9% (multi-AZ) |
| V2: Real-Time Online Learning + Multi-Tower | T3 | ~155ms (20ms retrieval + 30ms light + 80ms heavy + 10ms re-rank) | 100K RPS | $8,500/month | Very High | 99.9% (multi-AZ) |
This template is for educational and illustration purposes only. It may not represent the optimal production design for this problem. Real-world systems involve additional considerations (compliance, specific cloud provider constraints, organizational requirements) not captured here. Use this as a starting point for discussion, not as a production blueprint.
Frequently Asked Questions
Why is feed ranking the most common social-platform system design question?
Feed ranking combines five core distributed systems challenges: (1) candidate retrieval — efficiently finding posts from the user's interest graph, (2) relevance scoring — predicting which posts the user will engage with, (3) real-time feature engineering — computing engagement signals with sub-minute freshness, (4) ML model serving — running inference at 100K+ RPS with <100ms latency, and (5) content diversity — balancing engagement optimization with platform health. Meta, LinkedIn, TikTok, and Reddit ask it because it is their core product. Google, Amazon, and other tech companies ask it because it tests fundamental distributed systems concepts (fan-out, caching, stream processing) in a concrete product context that every candidate understands as a user.
Why does the query-time sort fail at scale?
The feed query computes a heuristic score for every post from every followed user in the last 7 days. With 500 follows and 10 posts/day each, that is 35,000 rows to scan, score, and sort. PostgreSQL must evaluate the heuristic formula for each row (3 function calls per row), materialize all scored rows in memory, perform a full sort (O(N log N) comparisons), and return the top 50. At 80K concurrent feed reads/sec, this creates enormous CPU pressure on a single PostgreSQL instance. Pre-computing candidates and caching in Redis (V1 approach) eliminates this entirely — the feed read becomes a simple key-value lookup returning pre-ranked post IDs in 2ms.
When should you switch from heuristic ranking to ML-based ranking?
Switch when you have sufficient engagement data to train a model (typically 1M+ engagement events) and when the heuristic ranking's quality ceiling becomes a measurable product problem. Concrete signals: (1) A/B tests show diminishing returns from tuning heuristic weights, (2) user engagement metrics (time-spent, DAU retention) plateau despite content growth, (3) user surveys indicate feed relevance dissatisfaction. For most platforms, the inflection point is around 1-10M DAU. Below 1M DAU, the heuristic approach is simpler to operate and the engagement data may be too sparse for ML. Above 10M DAU, ML-based ranking is table stakes — every major social platform uses multi-stage ML ranking.
How does the affinity score work in the heuristic formula?
The affinity score is a static, pre-computed value representing the viewer's historical interaction rate with each followed user. It is computed as: affinity(viewer, author) = (likes_on_author_posts + 2 * comments_on_author_posts + 0.5 * views_of_author_posts) / total_author_posts_seen. This produces a value between 0 and ~3 that is recalculated nightly via a batch job. The score captures historical preference but not real-time changes — if a user starts following a new account and engages heavily, the affinity score does not update until the next nightly batch. ML-based ranking (V1) uses real-time engagement features updated within seconds via the EngagementStream.
Why not cache the feed query results in Redis?
Feed query results are invalidated by three events: (1) any followed user publishes a new post, (2) any post in the feed receives new engagement (likes, comments), and (3) the viewer follows or unfollows someone. For a user following 500 accounts, invalidation events occur every few seconds — far too frequent for caching to be effective. The cache hit rate would be below 10%, and the invalidation logic (tracking which cached feeds contain which posts from which authors) is more complex than simply recomputing the query. The V1 approach solves this differently: it pre-computes candidate post IDs (not full rankings) via fanout-on-write, which is invalidated only on new posts, not on engagement changes.
Related Templates
Discussion
Sign in to join the discussion.
Ready to design your own Feed Ranking?
Open the simulator, place components on the canvas, wire them up, and run a traffic simulation to see how your architecture performs under real load.
Open Simulator