LinkedIn Professional Network  ·  View 14 of 30  ·  5 · Runtime

Feed Read — Critical Flow

One feed page in under 300 ms: three candidate sources, one ranker, and a deadline on every call.

Editable source SVG draw.io All views
Member app API layer Feed broker Feed inbox FollowFeed Recs + ads Features Content 1. GET /v1/feed?cursor 2. session to member context 3. feed page for member 4. inbox entries 5. high-degree timelines 6. top-k per shard (FPR) 7. recommended + ad candidates 8. timeout: drop, not fail 9. member + item features 10. second-pass rank 11. dedupe · diversity · ad slots 12. decorate URNs 13. hydrated, privacy-checked 14. ranked page + cursor 15. 200 · p95 ≤ 300 ms Feed Read — Critical Flow Inbox and feature returns are omitted; every call carries its own deadline inside the 300 ms budget. v 1.0 · owner Feed Engineering · date 2026-09

Decisions

  • The broker merges three candidate sources (inbox, FollowFeed, recommendations), so the storage strategy and the ranking can evolve separately
  • Every downstream call has a deadline inside the 300 ms budget; a late source is dropped, never waited for
  • Decoration happens last, so an edited or deleted post, and a changed privacy setting, take effect at read time

Latency budget (assumed split)

  • Session and context 15 ms · candidates 80 ms, fetched in parallel · features 40 ms
  • Second-pass rank 60 ms · decorate 50 ms · margin 55 ms
  • FollowFeed runs over 720 partitions with first-pass ranking on the index nodes (LinkedIn, 2016)

Risks

  • Decoration fans out to many services. Couchbase absorbs it, and a burst of cache misses is the most common cause of slow feeds
  • Actors with millions of followers concentrate FollowFeed reads, so their timelines are replicated
◀  Core Data Model All views Post Distribution — Hybrid Fan-out  ▶
Solution Architecture v1.0 · LinkedIn's own stack in LinkedIn-run colos · Enterprise Architecture · 2026-0914-feed-read-sequence