Design Twitter: System Design Interview Guide

Designing Twitter is a classic system design interview question that tests your ability to build a real-time, high-scale social network. With over 330 million monthly active users and billions of tweets per day, Twitter must handle massive write and read loads while maintaining low latency. In this guide, we'll walk through a complete system design for Twitter, covering requirements, data models, architecture, and key algorithms. We'll also explore trade-offs like fan-out on write vs. read, caching strategies, and sharding approaches. By the end, you'll be ready to tackle this question in any interview.

1. Requirements and Constraints

Start by clarifying functional and non-functional requirements. Functional: Users can post tweets, follow/unfollow users, view a timeline of tweets from followed users, and like/retweet. Non-functional: Low latency (feed load < 500ms), high availability, scalability to billions of tweets, and eventual consistency for feeds. Estimate scale: 200M daily active users, each posting 0.5 tweets/day = 100M tweets/day. Each user follows 200 on average, so feed generation needs to handle 200 * 100M = 20B fan-out operations daily.

2. Data Model and Storage

Design the schema. Users table: user_id (PK), name, email, etc. Tweets table: tweet_id (PK), user_id, text, timestamp, media_ids. Follows table: follower_id, followee_id (composite PK). Likes table: user_id, tweet_id (composite PK). For storage, use a relational DB (PostgreSQL) for user data and a NoSQL DB (Cassandra) for tweets and feeds due to high write throughput. Tweets are sharded by user_id to keep all tweets of a user together. Feeds are stored as a list of tweet IDs in Redis for fast retrieval.

-- Users table
CREATE TABLE users (
  user_id BIGINT PRIMARY KEY,
  name VARCHAR(100),
  email VARCHAR(100)
);

-- Tweets table (sharded by user_id)
CREATE TABLE tweets (
  tweet_id BIGINT,
  user_id BIGINT,
  text VARCHAR(280),
  created_at TIMESTAMP,
  PRIMARY KEY (user_id, tweet_id)
) WITH CLUSTERING ORDER BY (tweet_id DESC);

-- Follows table
CREATE TABLE follows (
  follower_id BIGINT,
  followee_id BIGINT,
  PRIMARY KEY (follower_id, followee_id)
);

3. High-Level Architecture

The system consists of several microservices: API Gateway, User Service, Tweet Service, Feed Service, Timeline Service, and Notification Service. The API Gateway routes requests and handles authentication. Tweet Service receives new tweets and writes to the database. Feed Service generates timelines using fan-out. Timeline Service serves the feed to users. Notification Service handles push notifications. Communication is asynchronous via message queues (Kafka) for fan-out and notifications.

4. Feed Generation: Fan-out on Write vs. Read

This is the core design decision. Fan-out on write: When a user tweets, pre-compute the feed for all followers by inserting the tweet into each follower's timeline cache. Pros: Fast reads. Cons: Heavy writes for celebrities with millions of followers. Fan-out on read: When a user loads their feed, fetch tweets from all followed users and merge them. Pros: No write amplification. Cons: Slow reads for users following many accounts. Hybrid approach: Use fan-out on write for users with fewer than a threshold (e.g., 10k followers) and fan-out on read for celebrities. This balances load.

def post_tweet(user_id, tweet_content):
    tweet_id = generate_id()
    save_tweet(user_id, tweet_id, tweet_content)
    followers = get_followers(user_id)
    if len(followers) < 10000:
        # Fan-out on write
        for follower_id in followers:
            add_to_feed(follower_id, tweet_id)
    else:
        # Fan-out on read: mark tweet for celebrity
        mark_celebrity_tweet(user_id, tweet_id)

5. Caching Strategy

Cache aggressively to reduce database load. Use Redis for: (1) User sessions, (2) Tweet IDs for each user's timeline (list of tweet IDs), (3) Popular tweets (full objects). Cache-aside pattern: On feed request, check cache; if miss, fetch from DB and populate cache. Set TTL based on recency. For celebrity tweets, cache the list of recent tweets to avoid DB queries on every feed load. Use a distributed cache like Redis Cluster for scalability.

def get_feed(user_id):
    feed_key = f"feed:{user_id}"
    tweet_ids = redis.lrange(feed_key, 0, 199)
    if not tweet_ids:
        # Cache miss: fetch from DB
        tweet_ids = fetch_recent_tweets_from_db(user_id)
        redis.rpush(feed_key, *tweet_ids)
        redis.expire(feed_key, 300)  # 5 min TTL
    # Fetch full tweet objects from cache or DB
    tweets = [get_tweet(tid) for tid in tweet_ids]
    return tweets

6. Sharding and Partitioning

Shard databases to handle scale. For tweets, shard by user_id (hash mod N) to keep all tweets of a user together, enabling efficient retrieval. For follows, shard by follower_id. For likes, shard by tweet_id. Use consistent hashing to minimize rebalancing. For the feed cache, shard by user_id. Each shard is a Redis node. Use a configuration service like ZooKeeper to manage shard mapping.

7. Handling Viral Events and Thundering Herd

When a celebrity tweets, millions of followers need feed updates. Use a message queue (Kafka) to buffer fan-out requests. Workers consume from the queue and update feeds in batches. Implement rate limiting to protect downstream services. For the feed read path, use a 'read-your-writes' consistency model: after posting, the user's own feed is updated immediately via a direct write to cache. For others, eventual consistency is acceptable.

def handle_celebrity_tweet(user_id, tweet_id):
    # Publish fan-out job to Kafka
    kafka.produce('fanout', key=user_id, value={'tweet_id': tweet_id})
    # Update own feed immediately
    add_to_feed(user_id, tweet_id)

# Worker
while True:
    msg = kafka.consume('fanout')
    followers = get_followers_batch(msg.user_id, batch_size=1000)
    for follower in followers:
        add_to_feed(follower, msg.tweet_id)

8. Timeline Ranking and Relevance

Twitter's timeline is not purely chronological; it uses a ranking algorithm to show relevant tweets first. Factors include recency, engagement (likes, retweets), and user affinity. Implement a scoring function: score = f(recency, engagement, affinity). Store scores in the feed cache along with tweet IDs. When serving the feed, sort by score. For simplicity, you can start with chronological and later add ranking.

def score_tweet(tweet, user):
    recency = (now - tweet.created_at).seconds
    engagement = tweet.likes + tweet.retweets * 2
    affinity = get_affinity(user.id, tweet.user_id)
    return 0.4 * recency + 0.3 * engagement + 0.3 * affinity

def get_ranked_feed(user_id):
    tweet_ids = get_feed_tweet_ids(user_id)
    tweets = [get_tweet(tid) for tid in tweet_ids]
    tweets.sort(key=lambda t: score_tweet(t, user_id), reverse=True)
    return tweets[:200]

9. Real-time Updates and Notifications

To support real-time updates, use WebSockets or Server-Sent Events (SSE). When a new tweet is added to a user's feed, push it to the user's active connection. For notifications (likes, retweets), use a separate notification service that listens to Kafka events and sends push notifications via Firebase/APNs. For simplicity, you can use polling with a long timeout, but WebSockets are preferred.

10. Monitoring and Observability

Monitor key metrics: feed load latency, tweet write latency, cache hit ratio, queue depth, and error rates. Use distributed tracing (Jaeger) to debug slow requests. Set up alerts for anomalies. Log all requests for auditing. Implement health checks for each service. Use a dashboard (Grafana) to visualize metrics.