Design Social Graph Analysis

Problem statement

Design a social graph analysis platform that stores and queries user relationship edges at planetary scale. The graph holds two primary edge types: friendship (bidirectional, symmetric) and follow (unidirectional, asymmetric). The platform must answer four classes of queries: (1) direct adjacency lookups such as "list Alice's friends," (2) multi-hop traversals such as "mutual friends of Alice and Bob," (3) graph-search queries such as "shortest connection path from Alice to Bob," and (4) candidate-generation queries such as "People You May Know" (PYMK) that score and rank non-connected users by structural and attribute similarity.

This is not a CRUD application. The defining characteristic is the read/write asymmetry. Facebook's TAO paper reports a read-to-write ratio exceeding 500:1 on social graph data. Every friend list render, every profile view, every mutual-friends badge, and every PYMK impression is a graph read. Edge creation — a friend request accepted, a follow added — is comparatively rare but must be durable, ordered, and visible to the requester within a bounded window.

Why the problem is distinctive

A relational database with a friends table works for a million users. It collapses at a trillion edges for three reasons. First, fan-out: a single mutual-friends query intersects two adjacency lists that may each contain thousands of entries, and a shortest-path query can explode into a breadth-first search touching millions of nodes. Second, partitioning: a graph is not naturally shardable by a single key because the hottest queries cross shard boundaries — Alice's friends live in one partition, Bob's in another, and the mutual-friends intersection must be computed across both. Third, skew: celebrity nodes with tens of millions of followers create read hotspots that a naive hash partition cannot absorb.

The four architectural planes

1. Storage plane: the durable edge store, partitioned by source node, holding adjacency lists as sorted or indexed collections.
2. Query plane: the read path that serves adjacency, intersection, traversal, and search queries with latency budgets.
3. Computation plane: offline and near-real-time pipelines that precompute PYMK candidates, degree counts, and graph embeddings.
4. Ingestion plane: the write path that accepts edge mutations, deduplicates them, orders them, and fans out cache invalidation and downstream events.

A strong answer keeps these planes separate. The query plane degrades gracefully under load; the storage plane never loses a committed edge; the computation plane can lag by hours without affecting the read path; and the ingestion plane must never block a read.

Public operating baseline versus design assumptions

Public evidence establishes that the category is real and enormous. Meta reports approximately 3.07 billion monthly active users across its Family of Apps. The TAO paper (USENIX ATC 2013) describes a system handling over one billion reads per second against a social graph that already exceeded one trillion edges at publication. LinkedIn reports over one billion members and operates the Economic Graph powering People You May Know. These are cited company figures, not requirements for our fictional system.

For capacity planning, this answer explicitly assumes a mature network with 2 billion registered users, 500 million daily active users, and approximately one trillion directed edge rows. Unless a number is tied to a citation, it is a stated design assumption, target, or budget — not a claim about any company's private architecture.