LinkedIn Professional Network

Who uses the network, what it depends on, and what has deliberately been left outside the line.

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

Who this is for, and what each of them actually gets to do with it, including the machines that act without being asked.

The journey with the most at stake for the member, and the silence after applying that decides how applications are stored.

The supply side of the feed, and why the first hour after posting shapes media, fan-out and ranking.

The paying customer's journey, where search relevance, member privacy and metered messaging meet.

What depends on what, and the one arrow that deliberately points back up.

The deployable units inside one colo, the technology of each, and the store it owns.

Every interface in and out, its protocol and cadence, and who owns the contract.

Record, derived, log and lake: which data is backed up and which is rebuilt.

The same data moving at three speeds, and the rule for which speed computes what.

Who publishes, who reacts, and why a publisher never knows its consumers.

The thirteen entities every service shares, and the keys that make ordering and idempotency properties of the data.

One feed page in under 300 ms: three candidate sources, one ranker, and a deadline on every call.

Push for normal authors, pull for high-degree ones, and recommended and sponsored content in lanes of their own.

Candidates, filter, score, policy, serve: the ranking is kept separate from feed storage, as the requirement asks.

The requirement's own example: a retried POST /connections must never create a second invitation.

Durable before acknowledged, ordered by one sequencer, delivered over SSE or by push.

An offline base index, a live buffer fed in seconds, and a federated query that personalises by graph distance.

One service owns the member's attention: it decides whether, when and on which channel they hear about something.

Bytes go straight from the client to Ambry, are scanned and transcoded, and are served from the CDN.

Four active colos, members pinned to one of them, and a colo drained as routine rather than as an emergency.

How a change reaches members, and the three things that stop a bad one.

How anyone knows the network is working, and who gets woken up when it is not.

How feed, search and jobs ranking improve: a loop that closes through what members actually do.

What each capability does when a dependency is slow, down, or in a lost colo, agreed before the incident.

Where the trust boundaries are, what crosses each one, and where an attacker arrives.

Who proves what to whom at sign-in, and how a session becomes a principal that services trust.

The checks every read of member data passes through, and why a block returns not-found.

Rules, models, member reports and human reviewers, all writing one decision log that can be audited.