Meta Social Feed Ranking And Fanout

What's being tested

Interviewers are probing a candidate’s ability to design a large-scale social feed that balances latency, cost, and freshness under heavy skew. Expect to justify a concrete fanout strategy, storage model, caching, and operational controls (rate-limiting, backpressure, SLAs). The interviewer wants clear tradeoffs, capacity math, and handling of hotspot users and failure modes — not a perfect ML ranking model.

Core knowledge

Push-based fanout: precompute timelines by pushing each update to all followers; write cost ≈ W * F where W is writes/sec and F is average followers; read cost is O(1). Great for low-read-latency but high write amplification and storage.
Pull-based fanout: compute feed on read by fetching recent posts from followees; write cost O(W), read cost ≈ O(following * candidate_cost). Better storage, higher read latency and CPU at query time.
Hybrid fanout: combine push for regular users and pull for celebrity accounts (heavy hitters) — reduces write amplification while keeping reads fast for most users.
Timeline vs. activity log: store a per-user timeline store (fast reads) and a global activity log (append-only, source-of-truth for recompute). Timelines are denormalized and cheaper to serve at p99.
Ranking pipeline: two stages — candidate generation (fast retrieval, e.g., recent posts, social graph signals) and scoring (ML model + heuristics). Precompute features where possible; keep scoring stateless for sharding.
Storage choices & tradeoffs: use Cassandra/HBase/Scylla for high-write per-key timelines, MySQL for control metadata, S3 for cold archives, Redis or memcached for hot timeline caching. Consider compaction and tombstone costs.
Capacity math and SLAs: compute ops and storage: writes/sec_total = W * F_push; storage_bytes ≈ avg_entry_size * followers * posts_retained. Target p99 read latency and budget costs per write/read.
Handling skew & hotspots: detect users with follower_count >> mean; route their updates to on-demand pipelines, sharded fanout workers, or materialize only top-K items per follower.
Consistency and freshness: eventual consistency is acceptable; strong consistency is expensive. Define freshness S (e.g., 1–5s) and design streaming/batching windows to meet it.
Backpressure and rate-limiting: burst control on ingestion, per-user throttles, queueing (e.g., Kafka partitions) and graceful degradation (serve older cached timeline).
Operational concerns: monitor p99 latencies, queue lag, write amplification, storage growth, and error budgets; plan for fanout backfills and replay from activity logs.

Worked example — "Design a news feed system that supports ranking and fanout"

Clarify requirements first: target users U, writes/sec W, average followers F, acceptable read p99 (e.g., <50ms), freshness requirement, retention window, and hot-account follower threshold. Organize the answer into three pillars: ingestion & fanout, storage & serving, and ranking & freshness. For ingestion, propose a hybrid fanout: push updates to timelines for users with follower_count < T (threshold), and keep celebrity posts in the activity log for pull-time candidate generation. For storage, use partitioned Cassandra tables keyed by user_id with timeline shards, and a Redis hot-cache for top-K recent items; explain compaction and TTL to control storage. For ranking, describe candidate generation from timeline + recent celebrity pulls, then a stateless scoring service that fetches precomputed features; flag the tradeoff: pushing reduces read latency but multiplies storage and write IOPS, while pulling saves writes at cost of read CPU and higher p99. Explicitly call out the capacity equation (writes_total = W_push * avg_followers_push) and a plan for sharding fanout workers by user_id. Close with "if more time": discuss cache invalidation, A/B experiment hooks, and how to backfill when ranking model changes.

A second angle — "Serve personalized feed on-demand with strict freshness for interactive UI"

This reframes priorities: reads are latency-sensitive and freshness <1s, so a pure pull model may violate SLOs. Propose a hybrid that precomputes only high-relevance candidates (e.g., friends, messages) and pulls lower-relevance or celebrity posts at read time. Use Kafka for near-real-time streams to keep a recent window (e.g., last 1,000 items) in an in-memory store, enabling sub-second freshness without pushing to all followers. Discuss caching partial ranked results per device-session to amortize repeated UI refreshes. Emphasize differences: read CPU and cache locality are now first-class concerns; you must dimension on read QPS and provision ephemeral state sharded by session or user.

Common pitfalls

Pitfall: Ignore skew and dimension by averages.
Designs that use average follower counts fail catastrophically when a few celebrities dominate writes; always show how hot accounts will be isolated (hybrid, sharding, rate-limits).

Pitfall: Treat ranking as only an ML problem.
Focusing solely on model quality without discussing candidate generation, precomputed features, and feature freshness leaves the system unservable at scale.

Pitfall: Not clarifying SLAs and cost constraints early.
Saying "low latency" without a quantifiable target prevents meaningful tradeoffs; state p99/p50 targets and a per-request cost or budget constraint.

Connections

This topic naturally pivots to stream processing (e.g., Kafka + stream processors), distributed caching and eviction policies, and backfill/replay strategies using append-only logs. Interviewers may also move toward SLO design and operational runbooks for incident response.