Design LinkedIn Feed

Problem statement

Design a professional network feed that shows each member a ranked stream of career-relevant content: posts from connections and followed members, long-form articles, company updates, job postings, endorsements, and recommended items such as people you may know and jobs you may want. The system must ingest content, moderate it, distribute it to the right audiences through fan-out, rank a personalized page of items in under 300 ms, support social actions (like, comment, repost), expose robust search over people and jobs, maintain a scalable connection graph, and provide recruiter messaging.

This is not a generic social timeline. Three properties make it distinctive. First, the social graph is a professional graph with hard product semantics: connections are mutual and capped (LinkedIn documents a 30,000 first-degree connection limit), follows are one-directional and uncapped, and second-degree distance drives both feed eligibility and people-you-may-know. Second, content carries professional context: visibility can be connections-only, public, or group-scoped; job posts and candidate signals have privacy constraints that casual social networks do not. Third, the degree distribution is extremely skewed. Most members have on the order of a hundred connections, while a small number of influencers, companies, and recruiters have millions of followers. Fan-out-on-write is cheap for the typical member and catastrophically expensive for the head of the distribution.

The central architectural tension

Feed systems live between two clocks. The write clock ticks when an author publishes: the system must decide immediately who will see the content. The read clock ticks when a member opens the feed: the system must assemble a ranked page in a few hundred milliseconds. Pushing work to write time (fan-out-on-write) makes reads trivial but multiplies writes by audience size. Pushing work to read time (fan-out-on-read) keeps writes cheap but makes every feed load an expensive merge. The correct answer is a hybrid: precompute mailboxes for normal audiences, pull high-follower authors at read time, and rank the merged candidates.

The four architectural planes

1. Ingestion plane: content creation, validation, moderation, media processing.
2. Distribution plane: fan-out engines, per-member feed mailboxes, serving cache.
3. Ranking plane: candidate generation, feature retrieval, ML scoring, blending policy.
4. Graph and recommendation plane: connection graph, people-you-may-know, job recommendations, search.

A separate messaging plane serves recruiter-candidate conversations with its own consistency and privacy needs.

Public operating baseline versus design assumptions

Public evidence establishes the category. LinkedIn announced more than one billion members in October 2023. LinkedIn engineering has publicly described Apache Kafka carrying trillions of messages per day through the company's pipeline, Venice as the derived-data store powering feed, search, and notifications, and Nori as its Lucene-based search stack. These are cited company figures, not requirements for our design. For capacity planning this answer explicitly assumes a mature network with 1 billion registered members, 300 million weekly active members, 100 million daily active members, 10 billion feed impressions per day, and a five-times event peak. Unless a number is tied to a citation, it is a stated design assumption.