Twitter System Design

Never dive directly into the design phase; it may raise red flags during the interview!


Interviewer: Design Twitter

Twitter is a social media platform where users post and interact with short messages called tweets.

1. Feature Expectations [5 mins]

You: Before we proceed, could you please clarify the use cases and scope for Twitter's system design? This will help me understand the main goals and functionalities we need to focus on.

Understanding the big picture will guide us in detailing how many users the system should handle, how fast it needs to perform, and what security measures are crucial.

Interviewer: We want to start with about 100 million active users initially, and we anticipate rapid growth. Our system needs to handle peak loads of up to 10,000 tweets per second. Security is our top priority—we must have strong measures in place to keep user data safe and prevent unauthorized access.

You: Thank you for the clarification. Based on this, let's outline the functional requirements of Twitter.

Functional Requirements

  1. Create Tweets
  2. View Tweets or News Feed
  3. Follow/Unfollow people
  4. Interact with tweets (like, reply, retweet)

These features are central to the user experience and represent the primary interactions on the platform.

To keep the discussion focused and manageable, I will not cover features like trends and hashtags, as these can be considered secondary and would require additional time to discuss comprehensively.

Target users of Twitter are individuals, celebrities, organizations, and advertisers. Knowing your audience helps tailor the design to meet their specific needs.

Limit the number of features discussed to one or two, as covering more can be time-consuming and may detract from explaining the most critical aspects of the design.


2. Estimations [5 mins]

Knowing how much data the system needs to handle and how fast it needs to process it is important for designing the system. It helps us make sure we have enough network and storage capacity to handle all the users and their activities without the system slowing down or having problems.

  • Assume daily active user base of 1 billion
  • On average, each user generates 2 posts per day
  • With each post averaging 50 KB in size, the total daily data generated amounts to approximately 100 terabytes (TB).
  • Total data per second: 10,000 tweets/second * 50 KB/tweet = 500,000 KB/second, approximately 512 MB/sec.
  • To handle this volume of 10,000 tweets per second, the Twitter system needs to support a network bandwidth of approximately 512 Megabits per second (Mb/s), with each tweet averaging 50 KB in size.

Clear estimations demonstrate planning and analytical skills crucial for system scalability and performance assessment.


3. Design Goals [5 mins]

Based on estimations and discussions, the non-functional requirements for the system include addressing critical aspects such as performance under high user loads, robust data security measures, and scalable infrastructure to accommodate rapid growth.

  1. Minimum latency
  2. High consistency
  3. Read heavy system

Specify latency/throughput targets and decide on consistency/availability levels based of estimations discussed for robust system design.


4. High-Level Design [5-8 mins]

To design a high-level system architecture for Twitter, we'll focus on the following aspects: APIs for read/write scenarios, the database schema, core algorithms, and the overall architecture for handling read and write operations.

I. APIs for Read/Write Scenarios

Defining APIs is important because it creates clear ways for different parts of the system to talk to each other. It helps keep things organized and makes it easier to change and add new features later on. APIs also make it possible for other programs or services to use the system's features in a controlled way, which helps with building and expanding the system smoothly.

Get Tweet

Endpoint Parameters Response
GET /tweets/{tweet_id} tweet_id Tweet data (tweet_id, user_id, text, timestamp)

Post Tweet

Endpoint Parameters Response
POST /tweets user_id, text, media Created tweet data (tweet_id, user_id, text, timestamp)

Follow User

Endpoint Parameters Response
POST /users/{user_id}/follow user_id, target_user_id Follow relationship data (user_id, target_user_id)

Unfollow User

Endpoint Parameters Response
DELETE /users/{user_id}/follow user_id, target_user_id Success or error message

Get News Feed

Endpoint Parameters Response
GET /users/news_feed user_id Array of post data (post_id, user_id, post_content, post_type, created_at)

II. Database Schema

The choice of database depends on the needs of the application. For SQL databases, like PostgreSQL or MySQL, are ideal for applications requiring strict data consistency, complex querying capabilities (e.g., JOIN operations), and transactions. They are well-suited for applications where data integrity and ACID (Atomicity, Consistency, Isolation, Durability) compliance are critical, such as financial systems or traditional enterprise applications.

However, for managing user profiles, tweets, and news feeds in a social media context, NoSQL databases offer advantages in terms of schema flexibility, horizontal scalability, performance with unstructured data, and seamless integration with object-oriented programming paradigms. These factors make NoSQL databases a pragmatic choice for accommodating the dynamic and rapidly evolving nature of social media data and user interactions.

Users Table

    {
        "user_id": "UUID",
        "username": "string",
        "email": "string",
        "password_hash": "string",
        "created_at": "timestamp"
    }

Tweets Table

    {
        "tweet_id": "UUID",
        "user_id": "UUID",
        "text": "string",
        "media_url": "string",
        "created_at": "timestamp"
    }

News Feed Table

    {
        "user_id": "UUID",
        "tweet_id": "UUID",
        "created_at": "timestamp"
    }

Ensure clear and concise communication of design choices and their implications to demonstrate deep understanding and critical thinking.


5. Deep Dive [10-12 mins]

Designing a system step by step helps us handle difficult problems by dividing them into smaller, easier tasks. This way, each part of the system gets careful planning and fits together smoothly. It also lets us make changes and improvements along the way, based on feedback and new needs, which helps create a strong and successful final product. Now, let's start designing the Twitter system!

1. Users

Users are individuals who interact with the social media platform. They can perform actions such as posting tweets, following/unfollowing other users, and viewing their news feed.

User Image


2. Load Balancer

The Load Balancer is critical for ensuring that the incoming traffic is evenly distributed across multiple servers. This helps in managing the load and ensuring high availability and reliability of the service. It prevents any single server from becoming a bottleneck.


3. API Gateway

It acts as a single point of entry for all API calls, consolidating various microservices or backend services behind a unified API interface. It performs tasks such as request routing, protocol translation, authentication, authorization, and traffic management (like rate limiting).

Key functionalities include:
  • /POST Tweet: Directs the request to post a new tweet.
  • /GET Tweets: Routes the request to retrieve tweets for the user.
  • /POST Follower: Handles the action of following another user.
The API Gateway abstracts the complexity of the backend services from the clients and provides a unified interface.


4. User Database

The primary database for storing user-related information is likely implemented using a graph database structure to efficiently manage and query intricate relationships and connections between users, enhancing performance for social interactions.


5. Tweet Database

The database for persistently storing all tweets, the database is implemented using a NoSQL solution, efficiently handles high volumes of unstructured data, ensuring scalability and fast read/write operations crucial for real-time interactions on Twitter.



6. News Feed Service

A service responsible for generating and managing users' news feeds (timelines). It utilizes caching and a separate database for efficient news feed generation.


Timeline Generation (News Feed Generation)

1. Push Model
New content is automatically sent to users' devices upon availability, ensuring prompt updates without user intervention.
I. Tweet Insertion: When a user tweets, the system fetches all their followers and inserts the tweet into each follower's news feed.
II. News Feed Retrieval: To populate a user's news feed, the system retrieves tweets from the news feed table and fetches additional tweet details from the tweet cache or database as needed.

2. Pull Model
Users manually request updates from Twitter's servers, granting them control over when they receive new content.
I. User Request: When an inactive user requests their timeline, the system fetches tweets from users they follow, merges them, and sorts by timestamp.

7. News Feed Database

The News Feed database stores users' personalized timelines, aggregating and storing tweets from followed users for efficient retrieval and display.


8. Notification Service

This service handles the delivery of notifications to users, such as when they receive mentions or interactions on their tweets.

High level architecture of Twitter


6. Futher Optimizations [2 - 5 mins]

1. Caching

Caching is essential for optimizing performance and scalability in a social media platform like Twitter. By storing frequently accessed data such as user profiles, tweets, and media content in memory, caching reduces database load and speeds up data retrieval. This ensures smooth and uninterrupted service, even during peak usage times or network fluctuations. Systems like Redis, Memcached, and cloud-based solutions like AWS ElastiCache and Microsoft Azure Cache for Redis play a crucial role by providing efficient, scalable caching mechanisms tailored to Twitter's real-time content demands.

Data Stored in Cache

  {
      "key": "string",
      "value": "string"
  }

I. User Cache

The User Cache is an in-memory data store that holds frequently accessed user data to provide low-latency access. It is used to quickly retrieve user information without repeatedly querying the User Database.

Example User Cache

  [
      {
          "key": "055222617429691216296134948919650608043",
          "value": {
              "user_id": "055222617429691216296134948919650608043",
              "username": "twitteruser",
              "email": "user@example.com",
              "password_hash": "a40e1c2480f5489e6c6f4592674a4cf4",
              "created_at": "2020-05-22 07:26:27"
          }
      },
      {
           ...
      },
  ]

II. Tweet Cache

The Tweets Cache stores recent tweets in an in-memory data store to facilitate quick retrieval. When a tweet is posted, it is first written to the cache to ensure that it can be served quickly to users requesting it.

Example Tweet Cache

  [
      {
          "key": "9fc9d913973592188cb15df207700a74",
          "value": {
              "tweet_id": "9fc9d913973592188cb15df207700a74",
              "user_id": "055222617429691216296134948919650608043",
              "text": "Hey there world!",
              "media_url": "https://example.com/some-url",
              "created_at": "2023-09-01 22:03:55"
          }
      },
      {
           ...
      },
  ]

III. News Feed Cache

The News Feed Cache holds the personalized timelines of users in an in-memory data store for quick access. This reduces the need to recompute the timeline each time a user requests it.

Example News Feed Cache

  [
      {
          "key": "082a2926b0c49f32870feb851c2e82e9",
          "value": {
              "user_id": "055222617429691216296134948919650608043",
              "tweet_id": "9fc9d913973592188cb15df207700a74",
              "created_at": "2023-09-01 22:03:55"
          }
      },
      {
           ...
      },
  ]


2. CDN (Content Delivery Network)

A distributed network of servers that caches and serves static content like images, videos, and other media assets for efficient delivery to users.

I. Push CDN
Push CDNs proactively distribute pre-cached content from origin servers to edge servers globally, optimizing availability and reducing latency for static content like images and videos.

II. Pull CDN
Pull CDNs fetch content from origin servers on demand, checking edge server caches first and dynamically caching new or updated content, ideal for dynamic websites needing real-time updates and flexibility in content delivery.

High level architecture of Twitter after Optimizations


7. Data Flow [5-8 mins]

It's essential to explain the end-to-end flow of the design, ensuring clarity on how data moves through the system. Based on estimations and discussions, the non-functional requirements for the system include addressing critical aspects such as performance under high user loads, robust data security measures, and scalable infrastructure to accommodate rapid growth.


Posting a Tweet:

  1. A user posts a tweet through the Internet.
  2. The request hits the Load Balancer and is routed to the API Gateway.
  3. The API Gateway processes the /POST Tweet request, storing the tweet in the Tweets Cache and Tweets Database.
  4. The News Feed Service updates the followers' news feeds.
  5. The Notification Service may notify followers about the new tweet.

Getting Tweets:

  1. A user requests their tweets through the Internet.
  2. The request goes through the Load Balancer to the API Gateway.
  3. The API Gateway processes the /GET Tweets request by checking the Tweets Cache.
  4. If the tweet is not in the cache, it fetches it from the Tweets Database.
  5. The tweet is then served back to the user.

Following/Unfollowing Users:

  1. A user follows or unfollows another user through the Internet.
  2. The request reaches the API Gateway via the Load Balancer.
  3. The API Gateway processes the /POST Follower request, updating the User Cache and User Database.
  4. The News Feed Service adjusts the follower's news feed accordingly.
  5. The Notification Service sends out notifications if appropriate.

News Feed Updates:

  1. The News Feed Service maintains and updates users' personalized timelines.
  2. For active users, it pushes updates in real-time.
  3. For inactive users, it updates the feed on-demand.
  4. Updated feeds are stored in the News Feed Cache for quick access and in the News Feed Database for persistence.

Don't forget to explain the end to end flow of your design!


This architecture is designed to be scalable, resilient, and efficient, ensuring that the platform can handle a high volume of user interactions and data processing with minimal latency and high availability.