Social Network System Design: Building the Graph That Connects Billions

Social networks sit at the intersection of nearly every hard problem in distributed systems: graph traversal, real-time fan-out, content ranking, privacy enforcement, and global consistency. Facebook serves over 3 billion monthly active users. Designing a system at even a fraction of that scale requires deliberate choices at every layer.

High-Level Architecture#

┌────────────┐    ┌────────────┐    ┌──────────────┐
│  Clients   │───▶│  API       │───▶│  Auth / Rate │
│  (Web/App) │◀───│  Gateway   │◀───│  Limiter     │
└────────────┘    └─────┬──────┘    └──────────────┘
                        │
        ┌───────────────┼───────────────────┐
        ▼               ▼                   ▼
 ┌────────────┐  ┌─────────────┐    ┌─────────────┐
 │  Graph     │  │  Feed       │    │  Messaging   │
 │  Service   │  │  Service    │    │  Service     │
 └─────┬──────┘  └──────┬──────┘    └──────┬──────┘
       │                │                   │
       ▼                ▼                   ▼
 ┌────────────┐  ┌─────────────┐    ┌─────────────┐
 │  Graph DB  │  │  Feed Cache │    │  Message     │
 │  / Adj.List│  │  + Store    │    │  Store       │
 └────────────┘  └─────────────┘    └─────────────┘

The User Graph#

The social graph is the core data structure. Every user is a node; every relationship (friend, follow, block) is an edge.

Adjacency List vs. Graph Database#

Adjacency list in a relational database:

CREATE TABLE friendships (
    user_id     BIGINT NOT NULL,
    friend_id   BIGINT NOT NULL,
    status      VARCHAR(20),  -- 'accepted', 'pending', 'blocked'
    created_at  TIMESTAMP,
    PRIMARY KEY (user_id, friend_id)
);

• Scales well for direct lookups ("are A and B friends?") and single-hop queries ("all friends of A").
• Multi-hop queries (friends-of-friends, shortest path) require expensive self-joins.
• Works at surprising scale when sharded by user_id.

Graph database (Neo4j, Amazon Neptune, Dgraph):

• Models relationships as first-class citizens with native index-free adjacency.
• Multi-hop traversals (2nd/3rd-degree connections, mutual friends) are orders of magnitude faster.
• Operational complexity is higher — fewer battle-tested sharding strategies than relational databases.

Hybrid approach (Facebook TAO): Store the graph in a sharded MySQL backend but serve reads through a graph-aware caching layer (TAO) that understands edges and nodes natively. This gives relational durability with graph query performance.

Friend Suggestions#

Friend suggestions drive network growth. The core algorithms:

1. Friends of friends (FoF) — For each of user A's friends, collect their friends. Rank by number of mutual connections. This is a 2-hop BFS on the graph.
2. Contact graph — Users upload phone contacts or email lists. Match against registered users. Weight by recency and frequency of contact.
3. Affinity signals — Shared schools, workplaces, locations, group memberships. These come from profile metadata and interaction patterns.
4. Embedding-based similarity — Train a graph neural network (GraphSAGE, Node2Vec) on the social graph. Users with similar embeddings but no direct connection are strong candidates.

Scaling FoF Computation#

For a user with 500 friends, each having 500 friends, FoF expands to 250,000 candidates. Pre-compute FoF scores in a batch pipeline (Spark) and store the top-K suggestions per user in a cache (Redis). Refresh daily or on significant graph changes (new friendship accepted).

News Feed#

The news feed is the product's heartbeat. Every time a user opens the app, the feed must render personalized, ranked content within 200 milliseconds.

Fan-Out Strategies#

Fan-out on write (push model):

• When user A creates a post, immediately write a reference to that post into the feed cache of every follower.
• Fast reads — the feed is pre-assembled.
• Expensive writes for users with millions of followers (the "celebrity problem").

Fan-out on read (pull model):

• When user B opens their feed, query all users B follows, fetch their recent posts, merge, and rank.
• No write amplification, but read latency is higher.

Hybrid (Facebook/Instagram approach):

• Fan-out on write for ordinary users (< 10K followers).
• Fan-out on read for celebrities. When building B's feed, merge the pre-assembled feed with a real-time fetch of celebrity posts.

Feed Ranking#

A raw chronological feed is simple but quickly becomes noisy. Modern feeds use ML ranking:

• Candidate generation — Collect the last N posts from followed users and relevant groups.
• Feature extraction — Post age, author affinity (how often B interacts with A), content type (photo, video, text), engagement velocity (likes in first 10 minutes).
• Scoring model — A neural network or gradient-boosted tree predicts a relevance score. Optimize for a weighted blend of engagement metrics: time spent, likes, comments, shares, and "meaningful social interaction" signals.
• Diversity injection — Penalize consecutive posts from the same author or content type to keep the feed varied.

Notifications#

Notifications re-engage users. The system handles multiple channels: push (APNs, FCM), in-app, email, and SMS.

• Event bus — Every significant action (like, comment, friend request, mention) publishes an event to Kafka.
• Notification service — Consumes events, applies user preference filters (muted users, quiet hours, channel preferences), batches low-priority notifications (daily digest), and dispatches to delivery providers.
• Deduplication — If 50 people like a post in quick succession, collapse into "50 people liked your post" rather than sending 50 individual notifications.
• Priority levels — Direct messages and mentions are high priority (immediate push). "People you may know" is low priority (batched).

Content Moderation#

At scale, moderation must be automated with human oversight:

1. Upload-time scanning — Images and videos pass through ML classifiers (nudity detection, violence, hate symbols) before publication. High-confidence violations are blocked immediately.
2. Text analysis — NLP models detect hate speech, harassment, and spam. Multilingual support is critical — toxicity manifests differently across languages and cultures.
3. User reporting — Reports feed a review queue prioritized by severity and reporter trust score.
4. Appeals workflow — Automated decisions can be appealed. Human reviewers re-examine flagged content with full context.
5. Behavioral signals — Accounts that post at inhuman speed, create identical content across many groups, or accumulate reports quickly are flagged for automated or manual review.

Privacy Controls#

Privacy is not a feature bolted on after launch — it must be embedded in the data model:

• Visibility levels — Each post carries an audience selector: public, friends, friends-of-friends, custom list, only-me. The feed service must evaluate visibility at query time.
• Access control at the graph level — Blocking user X means X cannot see your profile, posts, or appear in your search results. Implement as a check in every read path.
• Data portability — GDPR and other regulations require export of all user data on request. Build an export pipeline that traverses all data stores and assembles a downloadable archive.
• Deletion — "Delete my account" must propagate across every service: graph edges, posts, comments, messages, analytics events, ML training data. Use a distributed saga with verification.
• Consent management — Track granular consent (analytics, personalized ads, third-party sharing) in a dedicated consent service.

Messaging#

Direct messaging is effectively a separate real-time system:

• Protocol — Clients maintain persistent WebSocket connections to a presence/messaging gateway. Messages are delivered in real time when the recipient is online; otherwise queued for push notification and later retrieval.
• Storage — Messages are stored in a partitioned database (Cassandra, HBase) keyed by conversation ID and sorted by timestamp. Conversations with two participants use a deterministic conversation ID derived from both user IDs.
• End-to-end encryption (E2EE) — For private messaging, the server should never see plaintext. Use the Signal Protocol (Double Ratchet + X3DH key agreement). The server stores only ciphertext.
• Group messaging — Fan-out each message to all group members. For large groups (1000+ members), use a server-side fan-out with sender key encryption.
• Read receipts and typing indicators — Ephemeral signals sent via the WebSocket connection. Not persisted.

Media Upload#

Photos and videos are the highest-bandwidth content:

• Upload flow — Client requests a pre-signed URL from the API, uploads directly to object storage (S3), and notifies the API on completion. The API triggers post-processing (thumbnail generation, EXIF stripping, resizing to multiple dimensions).
• Image processing — Generate thumbnails (150px, 600px, 1080px) and convert to WebP/AVIF for bandwidth savings. Store all variants in object storage with a CDN in front.
• Video processing — Transcode into multiple bitrates and generate preview thumbnails. For short-form video (Reels, Stories), keep processing latency under 30 seconds.
• Content-addressable storage — Hash the file content to deduplicate. If two users upload the same meme, store it once.

Sharding by User ID#

At billions of users, no single database instance can hold the full dataset. Sharding is essential.

Strategy#

• Shard key: user ID — Hash the user ID to determine the shard. All of a user's data (profile, posts, friend list) lives on the same shard, enabling single-shard queries for profile views.
• Consistent hashing — Use a hash ring with virtual nodes to minimize data movement when adding or removing shards.
• Cross-shard queries — Fetching a news feed requires reading from multiple shards (one per followed user). The feed service issues parallel requests and merges results.
• Replication — Each shard has 2-3 replicas. Writes go to the primary; reads can hit replicas with eventual consistency.

Handling Hot Spots#

Celebrity accounts create hot shards. Mitigations:

• Read replicas — Add extra read replicas for shards containing celebrity data.
• Caching — Cache celebrity profiles and recent posts in Redis with a short TTL.
• Shard splitting — If a shard grows too large, split it. Consistent hashing makes this less disruptive.

Global Consistency#

A social network operates across continents. Users expect to see their own writes immediately, but can tolerate slight delays seeing others' updates.

• Read-after-write consistency — After a user creates a post, route their subsequent reads to the primary replica (not a potentially stale read replica) for a short window (e.g., 30 seconds).
• Causal consistency — If user A comments on user B's post, any user who sees A's comment must also see B's post. Enforce with logical timestamps (vector clocks or hybrid logical clocks).
• Conflict resolution — For concurrent edits (e.g., two users editing a group description), use last-writer-wins with a wall-clock timestamp, or CRDTs for collaborative fields.
• Multi-region deployment — Deploy in 5+ regions. Use asynchronous replication between regions (cross-region latency makes synchronous replication impractical). Accept that a user in Tokyo may see a post from New York with a 1-2 second delay.
• Session stickiness — Route a user's requests to the nearest region and keep them sticky to that region for the duration of a session to avoid reading stale data from a different region.

Key Metrics#

Final Thoughts#

A social network is a graph problem wrapped in a real-time system wrapped in a privacy and moderation challenge. The user graph is the foundation, but the real complexity lies in the interactions between subsystems — how the feed service reads the graph, how moderation gates the feed, how privacy controls constrain every query. Start with the graph, layer on the feed, and let every other service reference the same source of truth.

---

Design systems like this interactively at codelit.io.

This is article #188 in the Codelit system design series.