Design Facebook

Problem Statement

Design a social network like Facebook supporting a friend graph, news feed, posts (text/photo/video), comments, reactions, friend suggestions, and notifications. The system must handle 3B monthly users with a news feed that balances relevance ranking with freshness.

Requirements

Functional

• Manage social graph: send/accept/reject friend requests; mutual friendship model
• Post content (text, photos, videos) with privacy controls (public, friends-only, custom lists)
• Generate a personalized news feed ranked by relevance (engagement signals, recency, relationship closeness)
• Friend suggestions using mutual friends (friends-of-friends) and graph analysis

Non-Functional

• Latency: News feed loads in <1 second, post creation confirmed in <2 seconds
• Scale: 3B MAU, 2B DAU, average 338 friends per user, 500M posts/day
• Consistency: Eventual consistency for feed (1-5s delay acceptable); strong consistency for friend graph mutations
• Storage: Petabytes of photo/video content

Core Architecture

1. Social Graph Service -- Stores the friendship graph in a TAO-like system (graph database over MySQL shards). Each user is a node; friendships are bidirectional edges. Supports adjacency queries (list friends), membership queries (are A and B friends?), and traversal (friends-of-friends). Heavily cached -- friend lists change infrequently.

2. News Feed Service -- Hybrid fan-out model. When a user posts, the feed service pushes the post ID to each friend's feed timeline (Redis sorted set) for users with <5000 friends. For high-follower accounts, the post is pulled at read time. Feed ranking applies an ML model scoring: affinity (interaction history), content type weight, recency decay, and engagement velocity.

3. Friend Suggestion Engine -- Runs a nightly batch job computing friends-of-friends with overlap counts. "People You May Know" = users who share >3 mutual friends, weighted by interaction recency. Also incorporates signals like shared workplace, school (from profile), and phone contacts.

4. Notification Service -- Event-driven via Kafka. Actions (likes, comments, friend requests, mentions) produce events consumed by the notification service. Deduplicates and batches ("Alice and 5 others liked your post"). Delivers via push notification (APNs/FCM), in-app badge, and email digest.

Database Choice

MySQL (sharded) for the social graph (TAO layer) -- partitioned by user_id for locality. TAO provides a graph API over relational storage with a massive memcache layer. Cassandra for feed timelines -- write-heavy, time-sorted, partitioned by user_id. S3 + CDN for media. Redis for precomputed feed caches and online presence. Elasticsearch for people and post search.

Key API Endpoints

GET /api/v1/feed?cursor=\{score\}&limit=20
  -> Returns: \{ posts: [\{ post_id, author, content, reactions_count, comments_preview \}], next_cursor \}

POST /api/v1/posts
  -> Body: \{ content: "Hello world", media_ids: ["M1"], privacy: "friends" \}

POST /api/v1/friends/\{user_id\}/request
  -> Returns: \{ request_id: "FR-123", status: "PENDING" \}

Scaling Insight

TAO (The Associations and Objects) is Facebook's key innovation: a write-through, read-optimized cache over a sharded MySQL graph store. TAO ensures that every graph read (friend list, "is friend?" check) hits a nearby cache server rather than the database. With 99.8% cache hit ratio and sub-ms lookups, TAO makes the social graph feel like an in-memory data structure despite being backed by petabytes of MySQL data.

Key Tradeoffs

Original DosiBridge notes for Design Facebook

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Design Facebook is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Core Entity: For Design Facebook, decide the core entity before choosing tools; otherwise the design looks clean but fails when facebook changes.
• Read/Write Path: For Design Facebook, decide the read/write path before choosing tools; otherwise the design looks clean but fails when facebook changes.
• Contention Point: For Design Facebook, decide the contention point before choosing tools; otherwise the design looks clean but fails when facebook changes.
• Abuse Path: For Design Facebook, decide the abuse path before choosing tools; otherwise the design looks clean but fails when facebook changes.
• Recovery Workflow: For Design Facebook, decide the recovery workflow before choosing tools; otherwise the design looks clean but fails when facebook changes.

Design Facebook correctness boundary

For this problem, separate the user-visible action from background work. The correctness boundary is the smallest state transition that must not be duplicated, lost, or reordered. Naming that boundary makes the solution more original than a stock API/database/cache template.

Design Facebook scaling bottleneck

The first bottleneck should be described in the language of this system: a hot timeline, a contested seat, a busy wallet ledger, a media-processing queue, or a search index update delay. That bottleneck decides which component deserves the deepest interview discussion.

Production review question

If Design Facebook suddenly receives 10x traffic, which entity becomes contested first, and what queue, lock, shard, or cache protects that entity without hiding correctness bugs?

Practical metric to track

Track facebook health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Design Facebook, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.

Sources

• Design Facebook -- Reference
• Source: System-Design-Overview