How LinkedIn Scaled to 350 Million Users: From Leo Monolith to 750+ Microservices

Introduction

Josh Clemm, senior engineering manager at LinkedIn, describes how the company’s architecture evolved to handle explosive user growth.

Growth and Challenges

Since its 2003 launch, LinkedIn’s global user base grew from 2,700 in the first week to over 350 million today, serving thousands of web requests per second, with mobile traffic accounting for more than 50 %. The backend must process millions of queries each second.

Early Monolith – “Leo”

Initially LinkedIn ran a single application service called “Leo”, which contained all web servlets, business logic, and connected to a lightweight LinkedIn database.

Member Graph Service

To manage connections between members, LinkedIn built a separate graph service named “Cloud”, using Java RPC to decouple it from Leo. This service also fed data to a Lucene‑based search system.

Read‑Only Database Replicas

As traffic grew, the primary member‑information database became a bottleneck. LinkedIn introduced read‑only replica databases synchronized via an early version of Databus, offloading all read traffic and adding consistency logic between master and replicas.

Decomposing Leo – Service‑Oriented Architecture

Frequent crashes of the monolith led to a shift toward many small, stateless services. APIs and business logic were extracted into microservices, front‑end servers were added to render HTML, and a middle‑layer provided data‑model APIs. By 2010 there were over 150 services; today the count exceeds 750.

Caching Layers

To reduce load, LinkedIn added intermediate caches such as Memcache, Couchbase, and Voldemort for pre‑computation. Over time, many caches were removed, leaving only caches close to the data store to maintain low latency and horizontal scalability.

Kafka – Distributed Pub/Sub

To handle massive data‑pipeline needs, LinkedIn created a custom publish‑subscribe platform, Kafka, which provides near‑real‑time access to any data source, supports Hadoop jobs, and powers site monitoring. Kafka now processes more than 5 trillion events per day.

Inversion Project

At the end of 2011, LinkedIn launched the “Inversion” initiative, pausing feature development to focus on tooling, deployment infrastructure, and engineering efficiency.

Rest.li – Unified API Model

In the move to a service‑oriented architecture, the existing Java‑RPC APIs became inconsistent. LinkedIn built Rest.li, a data‑model‑centric, stateless RESTful API that works for non‑Java clients, decouples the API from the presentation layer, and resolves backward‑compatibility issues. Combined with D2 for client‑side load balancing and service discovery, LinkedIn now offers over 975 Rest.li resources and more than 1 trillion calls per day.

Super Blocks

Because many services generate hundreds of calls, LinkedIn introduced “Super Blocks” – groups of backend services exposed via a single API, allowing dedicated teams to optimize and control each client’s call graph.

Multi‑Data‑Center Deployment

To avoid single points of failure, LinkedIn runs services across three primary data centers and numerous global PoPs, ensuring high availability and fault tolerance.

Conclusion

The evolution from a single monolith to a highly distributed, microservice‑driven platform illustrates the architectural challenges and solutions required to support a social network of hundreds of millions of users.