Designing Facebook | System Design Interview

Designing Facebook involves building a scalable and highly available social networking platform that enables billions of users to connect, share content, and interact in real time. This article explains the complete system design of Facebook, covering its architecture, APIs, database design, scalability, and performance considerations.

• Understand how Facebook handles posts, feeds, likes, comments, friendships, notifications, and media at massive scale.
• Learn the high-level architecture, data model, APIs, caching, database choices, and techniques used to build a reliable and scalable social media platform.

1. Problem Statement

We need to design a Facebook-like social networking system that allows billions of users to connect, share content, and interact with each other. The system should be scalable, highly available, and capable of serving personalized content with low latency.

• Users should be able to create posts, share photos and videos, connect with friends, and interact through likes, comments, and shares.
• The system should provide personalized feeds, real-time notifications, reliable media delivery, and efficient content retrieval even under heavy traffic.

2. System Requirements

Before designing the system, we need to identify its functional and non-functional requirements. These requirements define the core features Facebook should provide and the quality attributes needed to support billions of users.

Functional Requirements

Functional requirements describe the core features that the system must support.

• Users should be able to register, log in, manage profiles, and connect with other users through friend requests.
• Users should be able to create, edit, and delete posts containing text, images, videos, and links.
• Users should be able to like, comment on, and share posts, as well as view personalized news feeds.
• Users should be able to send and receive real-time notifications for friend requests, likes, comments, and other activities.
• Users should be able to search for people, posts, pages, and other content.
• The system should support privacy settings that control who can view and interact with user content.

Non-Functional Requirements

Non-functional requirements define how well the system should perform under different conditions.

• Availability: The system should remain available with minimal downtime.
• Scalability: It should support billions of users and continuously growing traffic.
• Reliability: User data, posts, and interactions should be stored and processed reliably.
• Low Latency: Feeds, posts, and notifications should be delivered with minimal delay.
• Consistency: User profiles, posts, comments, and social relationships should maintain appropriate data consistency.
• Security: User authentication, authorization, privacy, and data transmission should be protected.

3. Capacity Estimation

Before designing the architecture, we need to estimate the expected traffic, storage, and server requirements. These estimations help us choose the appropriate infrastructure, database, cache, and scaling strategy.

Assumptions

3.1 Storage Estimation

Each post requires approximately 1 KB for its metadata, and around 500 million posts are created daily.

Daily Storage = 500 Million × 1 KB
= 500 GB/day
For 30 days,
Monthly Storage = 30 × 500 GB
= 15 TB

Estimated Storage: ~15 TB/month for post metadata, excluding images and videos.

3.2 Bandwidth Estimation

Based on the daily post metadata storage:

Bandwidth = 500 GB / 86,400 seconds
≈ 5.8 MB/s
≈ 46.3 Mb/s

Estimated Write Bandwidth: ~46 Mb/s for post metadata.

Since Facebook is highly read-heavy, the actual network bandwidth will be significantly higher due to feed reads, media delivery, comments, likes, and other operations.

3.3 Server Estimation

Assume a single application server can handle approximately 10 million requests per day.

Number of Servers = 1 Billion DAU / 10 Million
= 100 Servers

Estimated Application Servers: ~100 servers.

In practice, additional servers would be required for Feed, Post, Media, Search, Notification, and other services.

3.4 Requests Per Second (RPS) Estimation

Assume 500 million posts are created per day.

Post Write RPS:
= 500 Million / 86,400
≈ 5,787 requests/second
≈ 5.8K write RPS
With a 20:1 read-to-write ratio:
Read RPS ≈ 5,787 × 20
≈ 115,740 requests/second

Estimated Traffic: The system should be capable of handling approximately 120K+ requests per second for post-related operations, with additional capacity for peak traffic.

Note: These are approximate interview-level estimates. Actual Facebook traffic would be much higher because users perform many operations beyond creating posts, such as feed refreshes, likes, comments, shares, searches, and media requests.

4. High Level Design

The High-Level Design (HLD) describes the overall architecture of the Facebook system and explains how different components work together to provide a scalable, reliable, and low-latency social networking platform.

Core Components

After the diagram, explain each component one by one.

• Client: The client represents the Facebook application running on mobile, web, and desktop devices. It allows users to create posts, view feeds, interact with content, connect with friends, and manage their accounts.
• API Gateway: The API Gateway acts as the single entry point for all client requests. It authenticates requests, applies security checks, and forwards them to the appropriate backend services.
• Load Balancer: The Load Balancer distributes incoming requests across multiple application servers to prevent overload and improve system availability.
• User Service: The User Service manages user registration, authentication, profiles, privacy settings, and account information.
• Friend Service: The Friend Service manages friend requests, friendships, blocking, and user connections.
• Post Service: The Post Service handles creating, updating, deleting, and retrieving posts, including text, links, and media metadata.
• Feed Service: The Feed Service generates personalized news feeds based on friends, followed pages, user interests, and content-ranking algorithms.
• Comment Service: The Comment Service manages comments and replies associated with posts.
• Like Service: The Like Service processes likes and reactions on posts and comments.
• Media Service: The Media Service handles uploading, processing, compressing, and retrieving photos and videos.
• Search Service: The Search Service enables users to search for people, posts, pages, groups, and other content using optimized search indexes.
• Notification Service: The Notification Service sends notifications for friend requests, likes, comments, shares, messages, and other activities.
• Recommendation Service: The Recommendation Service generates personalized content, friend, page, and group recommendations based on user behavior and interests.
• Message Queue: A Message Queue such as Kafka enables asynchronous processing of notifications, feed updates, analytics, recommendations, and background tasks. It improves reliability and handles traffic spikes efficiently.
• Redis Cache: Redis stores frequently accessed data such as user sessions, popular posts, user profiles, and feed data to reduce database load and improve response time.
• Database: The database stores user information, friendships, posts, comments, likes, notifications, and other structured application data.
• Object Storage: Large media files such as images and videos are stored in object storage such as Amazon S3 instead of the primary database.
• CDN: The Content Delivery Network (CDN) caches images and videos closer to users to provide faster content delivery and reduce latency.

Request Flow

After explaining the components, describe how a post travels through the system.

• User creates a post containing text, an image, or a video.
• The request reaches the API Gateway.
• The Load Balancer forwards the request to a Post Service instance.
• The Post Service validates the request and stores the post metadata in the Database.
• If the post contains media, the Media Service uploads the media file to Object Storage.
• The Post Service publishes an event to the Message Queue (Kafka).
• A Message Consumer processes the event and updates the Feed Service.
• The Feed Service generates or updates feeds for the user's friends and followers.
• The Recommendation Service uses user activity and post interactions to improve personalized recommendations.
• The Notification Service sends notifications to relevant users when required.
• The CDN caches the uploaded media for faster delivery.
• When users open Facebook, the Feed Service retrieves the latest ranked posts and serves media through the CDN.

Data Flow

The data flow shows how posts, media, and user interactions move through different components of the Facebook system after a user performs an action.

• The client sends a request to the API Gateway, which authenticates and forwards it to the Post Service.
• The Post Service checks Redis Cache for frequently accessed user and feed information.
• Post metadata is stored in the Database, while media files are stored in Object Storage.
• The post event is published to Kafka for asynchronous feed generation, notifications, analytics, and recommendations.
• The Feed Service processes the event and updates personalized feeds.
• When users request their feeds, the Feed Service retrieves ranked content from the cache and database.
• Media content is delivered through the CDN to provide fast and efficient content delivery.

5. Technology Stack

Before designing the data model, it is helpful to identify the technologies used by different components of the Facebook system. The following technology stack is commonly used to build a scalable, reliable, and high-performance social networking platform.

6. Data Model Design

The data model defines how Facebook stores and manages users, friendships, posts, comments, likes, and media. A well-designed schema ensures efficient data storage, fast retrieval, and supports scalability as the number of users and interactions grows.

• Identify the core entities required for social networking and content sharing.
• Define relationships between entities to maintain data consistency.
• Select the appropriate database model based on scalability and performance requirements.

Core Entities

The Facebook system consists of the following core entities:

• User: Stores user profile information, account details, and preferences.
• Friendship: Maintains friend relationships and their status between users.
• Post: Stores post content, author, timestamp, visibility, and media references.
• Comment: Stores comments and replies made by users on posts.
• Like: Stores reactions given by users to posts and comments.
• Media: Stores metadata of uploaded images and videos.
• Notification: Stores notifications for friend requests, likes, comments, shares, and mentions.

Database Selection

A combination of SQL and NoSQL databases can be used depending on system requirements.

• SQL Database: Suitable for structured data such as user accounts, friendships, and authentication information.
• NoSQL Database: Suitable for posts, comments, likes, and activity data because it provides horizontal scalability and high write throughput.
• Graph Database: Can be used for social relationships and friend connections where relationship-based queries are important.
• Object Storage: Media files such as images and videos should be stored separately, while only their metadata and references are maintained in the database.

7. API Design

The API design defines how the Facebook client communicates with backend services to perform operations such as authentication, posts, friendships, comments, likes, and media sharing.

• Design REST APIs that are simple, scalable, and easy to consume.
• Use appropriate HTTP methods for different operations.
• Secure APIs using authentication mechanisms such as JWT or OAuth.

Authentication APIs

User & Friendship APIs

Post APIs

Interaction APIs

Media APIs

Sample Request

POST /api/v1/posts

{
  "userId": "user_101",
  "content": "Having a great day!",
  "mediaId": "media_567",
  "visibility": "friends"
}

Sample Response

{
  "postId": "post_789",
  "status": "created",
  "timestamp": "2026-08-10T10:30:45Z"
}

8. Low Level Design

The Low-Level Design (LLD) describes the internal structure of the Facebook system by defining the key classes, their responsibilities, and their interactions. It helps organize the application into modular and maintainable components.

Core Classes

The Facebook system can be designed using the following core classes:

• User: Manages user profile information, account settings, and social connections.
• Friendship: Manages friend requests and relationships between users.
• Post: Stores post content, author, timestamp, visibility, and media references.
• Comment: Stores comments and replies made by users on posts.
• Like: Manages likes and reactions associated with posts and comments.
• Media: Handles uploaded photos and videos associated with posts.
• Notification: Sends notifications for friend requests, likes, comments, shares, and mentions.
• FeedService: Generates and manages personalized news feeds for users.

SOLID Principles

The Facebook system follows SOLID principles to keep the code modular, maintainable, and easy to extend.

• Single Responsibility Principle (SRP): Each class has a single responsibility. For example, PostService manages posts, while NotificationService handles notifications.
• Open/Closed Principle (OCP): New reaction types or post types can be added without modifying the existing post and interaction logic.
• Liskov Substitution Principle (LSP): Different post or media types can be used wherever a generic post or media object is expected.
• Interface Segregation Principle (ISP): Services expose only the methods required by their clients, preventing unnecessary dependencies.
• Dependency Inversion Principle (DIP): High-level services depend on abstractions rather than concrete database, cache, or storage implementations.

Design Patterns

The following design patterns can be used in the Facebook system:

9. Scalability & Performance

Scalability and performance ensure that the Facebook system can handle billions of users and millions of concurrent requests while maintaining low latency, high availability, and fast content delivery.

• Caching: Redis Cache stores frequently accessed data such as user profiles, popular posts, trending content, and personalized feeds to reduce database queries and improve response time.
• Load Balancing: A Load Balancer distributes incoming requests across multiple API, Post, Feed, and Media servers, preventing overload and ensuring high availability.
• Database Replication: Database replication creates multiple copies of user data, posts, comments, and friendships to improve read performance and provide fault tolerance during server failures.
• Database Sharding: Sharding distributes users, posts, comments, and social relationships across multiple database servers, allowing the system to scale horizontally as the number of users and interactions increases.
• Asynchronous Processing: Kafka or other message queues process feed updates, notifications, likes, comments, analytics, and background tasks asynchronously, reducing response time for users.
• Horizontal Scaling: Additional Feed Servers, Post Servers, Media Servers, Search Servers, and Notification Servers can be added dynamically to handle increasing traffic without affecting existing users.
• CDN: A Content Delivery Network (CDN) caches images and videos closer to users, enabling faster content delivery and reducing latency across different regions.
• Rate Limiting: Rate limiting prevents excessive requests from a single user or device, protecting the system from spam, abuse, and denial-of-service attacks.
• Feed Optimization: Feed generation is optimized using precomputed feeds, caching, and ranking algorithms to deliver personalized content quickly, even during peak traffic.
• Media Processing: Dedicated media processing services compress images, transcode videos, and generate thumbnails asynchronously, ensuring fast uploads and efficient content delivery.

10. Bottlenecks & Improvements

This section discusses the potential challenges the Facebook system may face at scale and the techniques used to overcome them while maintaining high availability, low latency, and reliable content delivery.

• Identify common bottlenecks that can affect system performance.
• Apply suitable techniques to improve reliability, scalability, and fault tolerance.

Common Bottlenecks

As the number of users, posts, comments, likes, and feed requests grows, the Facebook system may encounter several bottlenecks that can impact performance and availability.

• Single Point of Failure (SPOF): A failure in a single server or service can make part of the system unavailable. Use redundancy, replication, and failover mechanisms to eliminate SPOFs.
• Database Bottleneck: A single database server may struggle under heavy read and write traffic. Database replication, sharding, and read replicas help distribute the load.
• Cache Misses: Frequent cache misses increase database queries and response time. Optimizing cache policies and caching popular content improves performance.
• Feed Generation Bottleneck: Generating personalized feeds for billions of users can require significant processing. Precomputed feeds, caching, and asynchronous processing help reduce the load.
• Message Queue Backlog: During traffic spikes, events may accumulate in Kafka. Partitioning and additional consumers help process events faster.
• Media Processing Bottleneck: Processing large images and videos can consume significant CPU and storage resources. Dedicated media processing servers and asynchronous processing help handle the workload.

Possible Improvements

The following techniques can further improve the scalability, reliability, and overall performance of the Facebook system.

• Auto Scaling: Automatically add or remove servers based on traffic demand.
• Failover Mechanism: Redirect traffic to healthy servers if a service, server, or database fails.
• Retry Mechanism: Retry failed background tasks, notifications, and event processing to improve reliability.
• Geo-Distributed Deployment: Deploy services and data across multiple regions to reduce latency for users worldwide.
• Feed Precomputation: Precompute and cache frequently requested feeds to reduce feed-generation latency.
• Content Delivery Optimization: Use CDN caching and adaptive media processing to deliver images and videos efficiently.
• Monitoring & Alerting: Continuously monitor system health, database performance, queue backlogs, and traffic patterns to detect failures and unusual activity early.