LinkedIn Professional Network  ·  View 02 of 30  ·  1 · Context and scope

High-Level Architecture

The shape of the platform in one picture: synchronous on the left, asynchronous from the event backbone onward.

Editable source SVG draw.io All views
Clients Web client SSR + SPA iOS / Android native Partner apps OAuth 2.0 Edge and API Azure Front Door global edge · TLS Traffic tier Apache Traffic Server API layer GraphQL over Rest.li Identity sessions · MFA Member services Profile Espresso Social graph LIquid Messaging SSE delivery Discovery services Feed FollowFeed Content posts · comments Search Galene Jobs postings · applies Event backbone Kafka the central log Samza nearline jobs Asynchronous consumers Recommendations Pro-ML · Venice Notifications ATC Analytics Pinot · HDFS LinkedIn — High-Level Architecture Application we own External / third party Interface / broker Security / platform Queue / topic Stores are omitted here; act 4 places every one of them. v 1.0 · owner Enterprise Architecture · date 2026-09

Decisions

  • Every client call enters through one API layer; no client calls a mid-tier service directly
  • A write lands in its system of record synchronously. Everything the write causes (fan-out, indexing, notifications, analytics) runs off the Kafka log
  • Each discovery service has a documented degraded mode that the profile, feed and apply paths survive

Targets (p95)

  • Profile read 200 ms · feed read 300 ms · post creation 300 ms · search 300 ms
  • Message delivery 500 ms · notification creation 1 s
  • 99.99% for identity, profile, feed, messaging and apply; 99.9% for search, recommendations and analytics

Deliberately omitted

  • Stores: act 4 places every one of them
  • Failure paths: views 26 (degradation) and 29 (privacy denials)
  • Ads serving internals, which ride the feed but are a separate system