Guides

LinkedIn Architecture Explained: How LinkedIn Builds Your Feed

By Ravindra Bagale, AWS & DevOps trainer · LinkedIn · Published: 18 October 2026 · Last updated: 18 October 2026

Short answer: LinkedIn is built from many microservices that talk using Rest.li, its open-source REST framework. Apache Kafka was created at LinkedIn and carries activity events; in 2019 LinkedIn ran 100+ Kafka clusters handling 7 trillion messages a day. Your feed is now retrieved by FishDB, a generic retrieval engine written in Rust (2025), and ranked by a new system powered by LLMs and GPUs (2026). Where LinkedIn's servers are hosted today is not publicly shared.

Suppose you open LinkedIn and scroll your feed

You open LinkedIn on the train to work in Mumbai and scroll your feed. In simple terms:

1. The app calls LinkedIn's front-end services, which call many Rest.li microservices.
2. The feed system asks FishDB to retrieve candidate posts, for example from your connections and topics you follow.
3. A ranking model built with LLMs, running on GPUs, scores posts by how relevant they are to your interests and career goals.
4. Profile and other member data comes from stores like Espresso, LinkedIn's distributed document store.
5. Every scroll, like and click is sent as an event to Kafka.
6. Those events help train the next ranking models.

What architecture style does LinkedIn use?

LinkedIn has shared a lot of its infrastructure as open source.

1. Microservices with Rest.li: services expose REST APIs through Rest.li, and LinkedIn has written about authorization between services at large scale.
2. Kafka-centric data flow: activity tracking, messaging and metrics all flow through Kafka.
3. New feed retrieval (2025): FishDB replaced FollowFeed, a Java system that powered the feed for nearly a decade. FishDB keeps a 40 ms p99 latency target while serving twice the queries per host, and cut feed hardware by about half.
4. Unified LLM ranking (2026): instead of several separate retrieval systems (trending, collaborative filtering, embeddings), LinkedIn is moving to LLM embeddings that better understand what posts are about.

LinkedIn architecture diagram (public parts)

This diagram shows only what LinkedIn or its partners have shared publicly. Press Play to follow a request step by step.

What does LinkedIn use? Main technologies

Which cloud provider does LinkedIn use?

Where LinkedIn hosts its services today is not publicly shared. LinkedIn is owned by Microsoft. The new ranking system (2026) runs on GPUs.

Why did LinkedIn build FishDB for the feed?

The 2025 change:

1. FollowFeed, a Java application built for connection-based feed content, served every LinkedIn feed for nearly a decade.
2. As feed use cases grew more complex, its design started to limit new features and efficiency.
3. FishDB is a generic retrieval engine written in Rust for modern recommender systems.
4. Results: the same 40 ms p99 latency target at twice the queries per host, about 50% less hardware for the feed, fast re-indexing, and business logic separated from infrastructure.
5. Experiments that took several weeks now take several days.

And the 2026 ranking change

Before, LinkedIn used several retrieval sources (trending content, collaborative filtering and embedding systems), each with its own infrastructure. In 2026 LinkedIn moved to a new ranking system powered by LLMs and GPUs that understands what a post is about. LLM embeddings help especially for new members and niche topics, where past behaviour data is thin. LinkedIn ranks millions of posts at any time while balancing freshness and relevance.

How it started: Kafka and Espresso

1. LinkedIn built Apache Kafka in-house as a stream processing platform and open-sourced it.
2. By 2019 LinkedIn ran over 100 Kafka clusters with more than 4,000 brokers, 100,000+ topics and 7 million partitions.
3. LinkedIn built Espresso, a distributed document store, to replace older storage for member data.
4. For almost ten years the feed was served by FollowFeed, a Java application.

How does LinkedIn store data?

1. Espresso: distributed document store.
2. FishDB: indexes feed content for fast retrieval and quick re-indexing.
3. Kafka: event streams.
4. Other storage systems and current sizes are not publicly shared.

How does LinkedIn monitor its systems?

LinkedIn's monitoring stack is not publicly shared. Kafka is used for metric gathering (2019).

If we built an app like LinkedIn on AWS (illustrative)

Suppose you want to build "KaamConnect", a professional network for skilled workers. Here is a simple AWS layout.

1. Network: VPC, subnets, route tables, gateways

1. Create one VPC with CIDR 10.0.0.0/16 in the Mumbai region (ap-south-1).
2. Use two Availability Zones (A and B), so one AZ failing does not stop the app.
3. In each AZ make three subnets: public (load balancer, NAT gateway), private app (your code) and private data (databases, cache).
4. Attach one internet gateway (IGW) to the VPC. Public route table: 0.0.0.0/0 → IGW. This route is what makes a subnet public.
5. Private app route table: 0.0.0.0/0 → NAT gateway, so servers can download updates but nobody can connect in from the internet.
6. Private data route table: only the local VPC route. Use VPC endpoints to reach S3, DynamoDB and SQS without going over the internet.

2. Compute: where the code runs

1. ALB in public subnets.
2. Services on EKS.
3. Activity events into Kinesis (or MSK for Kafka).

3. Storage and databases

1. Aurora for members and jobs.
2. DynamoDB for connections.
3. ElastiCache for feeds; S3 for photos and resumes; OpenSearch for search.

4. Monitoring

1. CloudWatch alarms.
2. X-Ray traces.

Request flow diagram

Press Play. The numbered list below the diagram lights up with each step.

LinkedIn versus our AWS design