System Design: LinkedIn

Start with a profiles table and a connections table in Postgres. Viewing a profile is a row read; connecting is an edge insert; the feed is a query over your connections' recent posts. Profile metadata is genuinely small — ~2 KB each is only a couple of terabytes for a billion members.

The edges are what break. ~1B users with ~500 connections each is on the order of 500B edges, and the queries that matter are graph-shaped: second-degree connections, 'people you may know', shortest paths for intro requests. A relational join over 500B rows is not a query plan, it is an outage.

Promote the edges into a dedicated distributed graph store partitioned by member ID, serving adjacency lists and bounded second-degree traversals from memory. Profile edits stay strongly consistent in the profile service — your own name must never be stale — while the profile service also publishes changes into a search index so member and company lookup becomes a search problem instead of a scan.

This split is the pattern for the whole design: one write path (the profile service) fanning into purpose-built read stores (graph, search). Say explicitly which store is authoritative — the profile DB — and that the graph and index are derived, rebuildable views.

The naive feed — recent posts from connections, newest first — is where most candidates stop, and it is wrong for LinkedIn: a member who logs in weekly should see the best of the week, not the last hour. Feed actions (~5B/day, ~58K/s) flow into Kafka; a feature pipeline computes signals (relationship strength, dwell time, content type) and an ML ranking service scores candidate posts into per-user feed caches.

The fan-out lesson from consumer social still applies: push ranked candidates for typical members, pull-and-merge at read time for mega-connectors and company pages with millions of followers. The hybrid is the same shape as Twitter's — say so, then point out the difference: here a ranking model, not recency, decides ordering.

The money is not the feed. The jobs service indexes postings into the same search infrastructure (filter by title, location, company) and powers a recruiter CRM whose queries — 'senior data engineers open to work in Berlin' — run against the search index and graph together. Applicant tracking is transactional and lives in its own store; a lost application is a lawsuit, not a stale cache entry.

Messaging (~200M messages/day, only ~2.3K/s) is modest in throughput but long in retention: conversations persist for years, so back it with Cassandra partitioned by conversation ID, with a push-notification bridge into APNs/FCM. Keep it a separate service — its consistency and retention needs share nothing with the feed.

Enterprise sales make privacy a feature, not a checkbox: per-section profile visibility, anonymous profile viewing, recruiter license boundaries, legal hold. Enforce it in a central privacy engine consulted on every read path — profile views, search results, feed items — rather than re-implementing ACL checks in each service, where one team's miss becomes a breach.

GDPR deletion is the follow-up interviewers love: a member's data lives in the profile DB, graph store, search index, feed caches, and message archives. A deletion pipeline walks every derived store from the authoritative record and proves completion into an audit log. If you designed clear derived-data lineage in step 2, this is a pipeline; if you did not, it is a manual incident.