# LinkedIn Professional Network

**Solution Architecture v1.0 · Enterprise Architecture · 2026-09 · 30 views · LinkedIn's own stack in LinkedIn-run colos**

A professional network architected at LinkedIn's published scale: 1.2 billion members, a 270-billion-edge graph served at 2 million queries a second, and trillions of Kafka messages a day. It is built mostly on the systems LinkedIn itself built (Rest.li, Espresso, Venice, LIquid, FollowFeed, Galene, Ambry, Kafka, Brooklin, Samza, Pinot), across 30 views and 33 architecture decision records.

Eight decisions carry the design:

- URN identifiers and schema-checked Rest.li contracts are permanent, while service boundaries are free to move.
- Systems of record (Espresso, MySQL, Ambry) are kept apart from derived serving stores (Venice, LIquid, FollowFeed, Galene). The derived stores are rebuilt from the Kafka log rather than backed up.
- Brooklin change capture replaces dual writes, so no derived store can silently diverge.
- The feed uses hybrid fan-out, with ranking kept separate from storage and content decorated at read time.
- Privacy is enforced on every read path, including derived copies, and a block returns not-found.
- Messages are ordered by one sequencer per conversation and delivered over Server-Sent Events.
- Every retryable write takes an idempotency key.
- Four active colos are drained on a schedule, and a written contract says what degrades when a dependency fails.

Thirty-three architecture decision records carry the reasoning for every component and technology on these views. Each gives what LinkedIn actually did, with dated sources, the alternatives that lost, what the choice costs, when to choose differently, and the transferable lesson. They are rendered on the landing page of the diagram set, directly below the index, and again as [docs/adr.md](docs/adr.md).

---

## What is here

| Path | Contents |
|---|---|
| `diagrams/index.html` | The landing page: 30 views grouped into seven acts, every format linked, and the full architecture decision record below the index |
| `diagrams/*.html` | One self-contained page per view: the inlined diagram plus the reasoning it leaves out, with copy / PNG / PDF export |
| `diagrams/svg/*.svg` | The same 30 views as SVG with the diagram XML embedded; they re-open in diagrams.net fully editable |
| `diagrams/drawio/*.drawio` | draw.io native source |
| `docs/adr.md` | The architecture decision record as markdown |
| `specs/views.json` | Diagram specifications, the source of truth for every view (assembled from `part-a..d.json`) |
| `specs/manifest.json` | Acts, page titles, subtitles and the decision / assumption / risk cards (assembled from `manifest-a..b.json`) |
| `specs/adr.json` | The 33 decision records, the capability-to-technology table and the LinkedIn stack glossary |
| `scripts/build.sh` | Rebuilds every deliverable from the specs |
| `scripts/pin-icons.mjs` | Pins one mark per component, and stops the resolver putting another product's logo on a LinkedIn system that has no mark of its own |
| `scripts/render-adr.mjs` | Validates `adr.json` and renders it into `diagrams/index.html` and `docs/adr.md` |
| `ask.md` | The original requirement |

To rebuild after editing a spec:

```bash
bash scripts/build.sh          # requires Node 20+ and nothing else
```

---

## The seven acts

| Act | What it lands | Views |
|---|---|---|
| 1 · Context and scope | The boundary, who touches it, and the shape of the platform in one picture | 01–02 |
| 2 · People and journeys | Members, hirers, operators and machines, plus the three journeys whose worst moments the rest of the set answers | 03–06 |
| 3 · Structure | The layering rule, the deployable units in a colo, and every interface in and out | 07–09 |
| 4 · Data | Which store owns what, what is rebuildable, the three speeds data moves at, and the shared entities | 10–13 |
| 5 · Runtime | Feed read, fan-out, ranking, connection, messaging, search, notifications and media | 14–21 |
| 6 · Operations | Colos and failure domains, delivery, observability, the ML loop, and the degradation contract | 22–26 |
| 7 · Assurance | Trust zones, identity, privacy on every read, and abuse defence | 27–30 |

---

## The views

| # | View | What it answers |
|---|---|---|
| 01 | System Context | Who uses the network, what it depends on, what is out of scope |
| 02 | High-Level Architecture | The shape of the platform in one picture |
| 03 | Actors and Their Core Journeys | Who it is for and what each of them gets to do, machines included |
| 04 | Journey — Job Seeker, Search to Status | Why silence after applying decides how applications are stored |
| 05 | Journey — Creator, Draft to Reach | Why the first hour after posting shapes media, fan-out and ranking |
| 06 | Journey — Recruiter, Search to First Reply | Where relevance, privacy and metered messaging meet |
| 07 | Layered Architecture | What depends on what, and the one arrow pointing up |
| 08 | Container Architecture | The deployable units in one colo and their technology |
| 09 | Integration Catalogue | Every interface in and out, and who owns the contract |
| 10 | Data Architecture and Ownership | Record, derived, log and lake: what is backed up and what is rebuilt |
| 11 | Data Flow — Online, Nearline, Offline | The same data at three speeds, and which speed computes what |
| 12 | Event Backbone | Who publishes, who reacts, and why neither knows the other |
| 13 | Core Data Model | Thirteen entities, and the keys that make order and idempotency properties of the data |
| 14 | Feed Read — Critical Flow | One feed page in under 300 ms |
| 15 | Post Distribution — Hybrid Fan-out | Push for normal authors, pull for high-degree ones |
| 16 | Feed Ranking Pipeline | Candidates, filter, score, policy, serve, with ranking apart from storage |
| 17 | Connection Request — Idempotent Flow | Why a retried POST /connections never makes a second invitation |
| 18 | Message Delivery | Durable, ordered, delivered over SSE or by push |
| 19 | Search — Indexing and Query | An offline base index, a live buffer, and a federated, personalised query |
| 20 | Notifications | One owner of the member's attention |
| 21 | Media Pipeline | Signed direct upload, scan, transcode, CDN |
| 22 | Deployment Topology | Four active colos, and what a colo loss costs |
| 23 | Delivery Pipeline, Canaries and Ramps | How a change reaches members and what stops a bad one |
| 24 | Observability and Operations | How anyone knows it is working, and who gets woken up |
| 25 | Relevance ML Lifecycle | How ranking improves from what members do |
| 26 | Graceful Degradation Contract | What each capability does when a dependency fails |
| 27 | Security Zones | Trust boundaries and where an attacker arrives |
| 28 | Identity and Access Flow | Sign-in with risk-based step-up, and a session becoming a principal |
| 29 | Privacy and Authorization | The checks on every read, and why a block returns 404 |
| 30 | Abuse Detection and Content Moderation | Rules, models, reports and reviewers writing one decision log |

---

## Evidence and assumptions

LinkedIn facts come from LinkedIn's engineering blog, Apache project records and the LinkedIn newsroom, and each decision record lists its dated sources. Published figures are as of their dates, not current counts. Three widely reported items were not traced to a primary LinkedIn source, and are marked where used: the Leo monolith, the 2011 Project Inversion freeze and the 2012 password breach. Where LinkedIn has not published how it does something (identity, member-privacy enforcement, messaging partitioning, intra-colo fault zones), the record says so and the decision is this design's own. Volumes other than the member count are planning assumptions and are labelled as such on the cards.