LinkedIn Feed

Assume 300M daily active members, each opening feed 8 times per day, and each request returning 20 visible items after scoring roughly 500 candidates. Assume 30M new feed-eligible items per day across posts, articles, videos, job updates, polls, reshared updates, and company updates.

Assume 5B engagement and impression events per day, including views, clicks, reactions, comments, hides, skips, and dwell-time beacons. Assume 15B graph edges after storing bidirectional connections as two directed edges and one-way follows as one directed edge. Use a 10x peak multiplier for regional daytime spikes.

• Feed requests: 300M daily active members times 8 feed opens is 2.4B requests per day. 2.4B divided by 86,400 seconds is about 27,778 read QPS, rounded to 27,800. With a 10x peak, plan for about 278,000 read QPS.
• Content writes: 30M feed-eligible items per day divided by 86,400 seconds is about 347 writes per second. With a 10x peak, plan for about 3,470 writes per second.
• Ranking work: 2.4B daily feed opens times 500 candidate items means 1.2T candidate scoring decisions per day before pruning, deduplication, and pagination.
• Visible impressions: if each feed open shows about 20 items, the system records about 48B potential visible slots per day. Not all become true impressions because users may stop scrolling before every item is viewed.
• Event volume: 5B engagement and dwell-time events per day at 300 bytes each is about 1.5 TB raw per day. A 90-day hot analytics window is about 135 TB raw before replication, compression, and indexes.
• Feed item storage: 30M items per day times about 3 KB metadata is about 90 GB raw per day. One year is about 33 TB raw before media storage, search indexes, replicas, and compaction overhead.
• Graph storage: 15B directed edges times roughly 64 bytes is about 960 GB raw. With replicas, adjacency indexes, tombstones, and edge attributes, reserve several TB.
• Cache memory: caching 200 candidate IDs plus small feature snapshots for 50M recently active members can exceed 500 GB after object overhead. Use tiered cache and refresh lazily.

• graph_edges.source_id, edge_type, status supports adjacency lookup for candidate generation.
• graph_edges.target_id, edge_type supports reverse fanout and audience estimation.
• feed_items.actor_id, created_at supports fetching recent actor activity.
• feed_items.dedupe_key helps suppress repeated stories.
• feed_events.member_id, occurred_at supports recent negative feedback and dwell features.
• materialized_feed_candidates.member_id, pre_rank_score, inserted_at supports quick candidate reads for active members.

Members create feed items and own outgoing graph edges. A bidirectional connection is represented by two active directed edges, while a follow is one directed edge. Feed events reference both the member and the feed item so the ranking pipeline can learn from impressions, reactions, hides, and dwell time.

The online feed service should not perform a relational join across all tables for each page. It reads candidate IDs from cache or materialized candidate storage, hydrates compact item records, asks the graph and privacy layer for eligibility, and sends features to the ranker.

At large scale, use specialized stores: a graph or adjacency-list KV store for edges, a document or wide-column store for feed item metadata, an event log such as Kafka for interactions, an OLAP lake for analytics, and Redis or a distributed cache for materialized candidates.

The graph store should support fast outgoing adjacency lookup, reverse lookup for fanout estimation, and edge attributes such as relationship strength. The feed item store should be partitioned by feed_item_id and optionally by actor_id for creator timelines. The materialized candidate store is naturally keyed by member_id with time-bucketed candidate lists.

LinkedIn has more relationship types than a generic friend graph. A connection is bidirectional and usually implies stronger visibility and trust. A follow is one-way and means interest without reciprocal access. Companies, schools, groups, topics, newsletters, creators, and jobs are also graph entities.

A practical store represents everything as directed edges with attributes: edge type, status, created time, source, target type, interaction strength, privacy flags, and recent engagement. When two members connect, write two active directed edges. When one member follows a company, write one edge.

Candidate generation should weight degree differently. First-degree connection posts are strong candidates, followed company updates are intent-driven candidates, and second-degree posts need proof such as shared industry, mutual connections, job relevance, or high-quality engagement. Blocks and mutes must be negative edges checked before ranking.

Pure fanout-on-write is expensive for high-degree creators, large companies, and job boards because one post could write to millions of member inboxes. Pure fanout-on-read is too slow for every feed open because it must scan many actors and rank too much fresh content.

Use hybrid fanout. Normal members and moderate-degree creators fan out candidate IDs to active followers and close connections. High-degree creators, companies, jobs, and viral stories are stored in actor timelines and pulled during feed read based on relevance and quotas. Inactive members receive fewer precomputed candidates and are refreshed lazily when they return.

The threshold should be dynamic. Fan out more when the author has a small, high-affinity audience. Pull more when the audience is huge, low-affinity, or content quality is uncertain. This keeps freshness without turning celebrity and company posts into write amplification events.

Professional relevance is not the same as entertainment engagement. A job opening, hiring manager post, industry article, or colleague promotion may be valuable even if it generates fewer likes than a viral meme. The ranking objective should combine member value, professional intent, trusted engagement, and long-term satisfaction.

Feature groups include graph strength, connection degree, shared employer or school, industry overlap, skills, job-seeking intent, content type, author reputation, freshness, quality, topic embedding similarity, dwell time, hides, reports, and downstream actions such as follows or applications. Dwell time is useful but must be normalized by content type because long articles and videos naturally produce longer dwell.

The ranker should use guardrails: downrank engagement bait, enforce content diversity, protect close-network updates, and avoid over-personalization that traps members in one industry or company bubble. Explainability matters because members may ask why they saw a professional update.

LinkedIn generates many repeated stories: multiple people congratulate the same job change, several connections reshare the same article, a company posts a job that also appears in job recommendations, and a poll may receive many comments. Without deduplication, the feed feels noisy.

Assign a dedupe key by canonical entity and event type, such as job_change plus member id, article_url plus normalized URL, job_id plus company id, or poll_id. Collapse repeated stories into one feed card with social context. Keep a per-ranking-session seen set in the cursor so pagination remains stable while fresh items arrive.

Diversity rules should cap consecutive items from the same actor, company, content type, or story family. The goal is not random variety; it is a balanced professional feed that mixes close-network updates, followed entities, jobs, articles, and timely conversations.

Second-degree candidates are important because they expose opportunities beyond direct connections: a hiring manager followed by a colleague, a founder in the same industry, or a post gaining traction among people with similar skills. They also risk feeling irrelevant or privacy-invasive if overused.

The feed should require stronger evidence for second-degree content than for first-degree content. Useful signals include multiple mutual connections, shared company or school, industry affinity, topic interest, recruiter or job-seeking intent, and high-quality engagement from trusted members. The ranking reason should be explicit, such as popular among people in your network or from a company you follow.

The economic graph angle means entities such as members, companies, jobs, skills, schools, industries, and content topics all participate in relevance. A feed item can be relevant because it connects a member to a job opportunity, a sales prospect, a hiring trend, or a professional learning topic.

Notifications should not be a copy of the feed. They should be reserved for high-signal events: connection requests, accepted connections, mentions, comments on your post, job changes from close connections, hiring updates matching intent, and important company activity.

The notification pipeline consumes the same activity bus but applies stricter thresholds, deduplication, quiet hours, channel preferences, and fatigue controls. It may send push, email, in-app badges, or no alert. Feed ranking can show lower-priority items later without interrupting the member.

This separation improves trust. A noisy feed can be tolerated briefly; noisy professional notifications cause churn and can feel like spam. The system should coordinate dedupe keys so a member does not receive repeated notifications and then see the same story multiple times in feed.

Alternative one is pure fanout-on-write. It is simple for reads and works for small networks, but high-degree creators, companies, and jobs create huge write amplification.

Alternative two is pure fanout-on-read. It avoids materialized inboxes but makes every feed open scan graph edges and actor timelines, which is too slow for hundreds of millions of members.

Alternative three is a chronological feed. It is easy to explain and cheap to rank, but it misses professional relevance, job intent, second-degree opportunities, and content quality signals.

Alternative four is an ML-only black-box ranker. It may optimize engagement, but without rules and guardrails it can over-promote noisy content, weaken trust, and fail to explain professional relevance.

Do not use this full design for a small internal company news feed or a simple chronological activity stream. A single database, basic follow table, and freshness ordering are enough until graph size, ranking quality, and fanout cost become real constraints.