LinkedIn Feed And Notification Fanout

What's being tested

This topic tests whether you can design a distributed fanout system that propagates one member’s activity to many followers while meeting latency, availability, ordering, and correctness requirements. For LinkedIn, a single post, connection update, or job change may affect millions of feed readers and notification recipients, so naïvely writing directly to every follower does not scale. The interviewer is probing whether you can decompose the system, choose push versus pull deliberately, handle retries and duplicates, and explain behavior during celebrity posts, failures, and traffic spikes.

Core knowledge

Fanout-on-write materializes a post into followers’ feed stores when it is created; reads are cheap and predictable, but writes can become enormous for highly followed members. Fanout-on-read stores the post once and merges followed authors’ posts at request time; writes are cheap, but reads require more work and have less stable latency.
A practical design uses a hybrid fanout: push to ordinary followers, but keep very large accounts in a pull path. Define a threshold using measured follower counts and traffic, not a magic constant; a 10-million-follower author cannot synchronously generate 10 million feed mutations.
Separate the activity log from materialized feed state. An append-only event in Kafka or a durable log is the source for asynchronous workers, while per-member feed entries live in a database such as Cassandra, RocksDB, or a sharded relational store.
Treat every delivery operation as at-least-once unless the entire path has stronger guarantees. Consumers must be idempotent using an event ID, such as (actor_id, activity_id, recipient_id), with conditional writes or deduplication records; retries must not create duplicate feed cards or notifications.
Use partitioning to distribute work by recipient or actor. Recipient partitioning balances feed updates and makes a member’s feed localized, while actor partitioning preserves event order but can create hot partitions for high-follower accounts; hot-key mitigation is essential.
Model ordering explicitly. Store an event timestamp plus a monotonic sequence or log offset, then define whether the API guarantees global order, per-author order, or only best-effort recency. Clock timestamps alone are unsafe because machines can disagree and events can arrive late.
Use backpressure and bounded queues between ingestion, fanout, and persistence. When consumers lag, preserve the durable source event, shed noncritical work such as low-priority notifications, and expose lag metrics rather than allowing unbounded memory growth.
Design separate notification delivery from feed materialization. In-app notifications can be persisted and fetched, while email, push, and SMS need channel-specific workers, rate limits, provider retries, suppression rules, and deduplication; a failed email provider should not block feed writes.
Make APIs and workers resilient to partial failure. A post-creation request should acknowledge after durable acceptance rather than waiting for every follower update; retry with exponential backoff and jitter, use dead-letter queues for poison events, and provide replay or repair tooling.
Cache read-heavy feed pages with a clear invalidation strategy. Cursor-based pagination is safer than offset pagination under concurrent inserts; a cursor should encode a stable ordering key such as (created_at, activity_id), and the system must tolerate deleted or privacy-restricted entries.
Account for membership and visibility changes during asynchronous processing. Before serving or materializing an entry, enforce blocks, unfollows, audience restrictions, and deleted-content tombstones; otherwise a delayed worker can expose content that was valid only when the event was created.
Define operational targets using measurable SLOs, such as event acceptance latency, time-to-feed-visibility, notification delivery latency, duplicate rate, queue lag, and p99 read latency. Monitor by shard, region, actor size, and channel so a global average does not hide celebrity-induced failures.

Worked example

For the representative prompt “Design LinkedIn Feed and Notification Fanout”, I would first clarify whether the requirement is feed-only or also email and push notifications, the expected read and write rates, freshness goals, ordering guarantees, privacy constraints, and acceptable delay for asynchronous fanout. I would declare that post creation returns after the event is durably recorded, while feed visibility is eventually consistent within a stated target such as a few seconds. I would organize the answer around four pillars: durable activity ingestion, hybrid fanout, per-member feed storage and cursor reads, and independent notification pipelines. I would then describe an idempotent consumer using an activity ID, recipient ID, and conditional insert so retries cannot duplicate entries. The key tradeoff is push versus pull: push gives fast, cheap reads for normal accounts, while pull prevents a highly followed account from creating an unbounded write storm. I would explicitly discuss backpressure, partition hot spots, privacy checks, retries, and observability rather than claiming “exactly once” end to end. I would close by saying that, with more time, I would specify shard sizing, multi-region failover, repair jobs, and load-test scenarios for a celebrity post and a regional queue outage.

A second angle

A notification-focused variant has different constraints from a feed, even though both begin with an activity event. Notifications require per-channel preferences, aggregation such as “five people reacted,” provider-specific retries, and stronger deduplication so one action does not generate repeated alerts. The system should therefore use a notification policy and aggregation layer before channel delivery, rather than treating every follower as a direct push recipient. Feed materialization can tolerate seconds of delay, while mobile push may require fast delivery but must also respect rate limits and quiet hours.

Common pitfalls

Pitfall: Saying “fan out synchronously to all followers” ignores tail latency and makes one large account able to exhaust request threads, database connections, or queue capacity. Use durable asynchronous work and explain a hybrid strategy for high-degree actors.

Pitfall: Claiming exactly-once delivery because Kafka or a database is involved is too strong. Most practical systems provide at-least-once processing with idempotent writes, deduplication, and reconciliation.

Pitfall: Discussing only the happy-path architecture misses the Software Engineer depth interviewers expect. Explicitly cover retries, poison messages, hot partitions, privacy changes, deletion, lag monitoring, and how the system recovers after a worker or region failure.

Connections

An interviewer may pivot to consistent hashing, event-driven architecture, idempotency, cursor pagination, multi-region replication, or backpressure. They may also ask how feed ranking is layered on top of the candidate-generation and fanout system without making ranking correctness a prerequisite for durable delivery.

Visa Tools

Visa Sponsors

H-1B Odds Calculator

Visa Bulletin