Twitter/X Architecture

​

Overview

Twitter (now X) is one of the most influential social media platforms, enabling real-time communication and information sharing across the globe. With over 400 million monthly active users posting hundreds of millions of tweets daily, Twitter’s architecture has evolved significantly to handle massive scale while maintaining real-time performance. This case study examines Twitter’s technical evolution, architecture patterns, and the sophisticated systems powering the “For You” timeline.

​

Architecture Evolution: 2012 vs 2022

Over the past decade, Twitter’s architecture has undergone dramatic transformation to support increased scale, new features, and better user experience.

​

Key Changes

​

Twitter 1.0 Tech Stack

​

Frontend Technologies

Mobile Applications

iOS:

• Swift: Native iOS development
• Platform-specific optimizations
• Offline capabilities

Android:

• Kotlin: Modern Android development
• Material Design guidelines
• Performance optimizations

Progressive Web App (PWA):

• Web-based mobile experience
• Reduced data usage
• Faster initial load

Web Application

Technology Stack:

• JavaScript/TypeScript: Core language
• React: UI framework
• Redux: State management

Architecture:

• Component-based design
• Server-side rendering
• Code splitting for performance
• Progressive enhancement

​

Backend Services

Service Infrastructure

Apache Mesos:

• Cluster management
• Resource allocation
• Service orchestration
• Multi-tenant infrastructure

Finagle:

• RPC framework (built by Twitter)
• Protocol-agnostic
• Async, concurrent programming model
• Circuit breakers and retry logic
• Service discovery integration

Key Features:

• Fault tolerant
• Load balancing
• Connection pooling
• Observability built-in

​

Caching Layer

​

Database Architecture

Manhattan - Distributed Database

Twitter’s custom distributed database:Architecture:

• AP system (Available and Partition-tolerant)
• Eventually consistent
• Multi-datacenter replication

Use Cases:

• User profiles
• Tweet storage
• Social graph
• Timeline data

Features:

• Horizontal scalability
• Multi-tenancy
• Automated sharding
• Hot data rebalancing

MySQL

Used for:

• Transactional data
• User authentication
• Billing and payments
• Strongly consistent data

Sharding Strategy:

• Horizontally partitioned
• ID-based sharding
• Cross-shard queries minimized

PostgreSQL

Used for:

• Analytics workloads
• Complex queries
• Reporting systems
• Internal tools

​

Recommendation System: “For You” Timeline

​

The Five-Stage Pipeline

Twitter’s recommendation system is one of the most sophisticated in the industry, involving multiple stages to deliver personalized content:

​

Stage 1: Candidate Sourcing

Starting Point: ~500 million tweets

Candidate Sources

In-Network Sources:

• Tweets from users you follow
• Recent tweets (recency-based ranking)
• Popular tweets from your network

Out-of-Network Sources:

• Tweets from similar users
• Trending topics
• Collaborative filtering
• Content-based recommendations

Embedding-Based Retrieval:

• User embeddings
• Tweet embeddings
• Cosine similarity search
• Vector databases (Faiss)

​

Stage 2: Global Filtering

Result: ~1,500 candidates Filters Applied:

• Remove blocked/muted users
• Filter out tweets you’ve seen
• Remove tweets that violate policies
• Deduplicate similar content
• Age filter (too old tweets removed)
• NSFW filtering based on settings

Performance:

• Must process 500M tweets quickly
• Distributed filtering across clusters
• Cached filter results

​

Stage 3: Scoring and Ranking

The Core Ranking Model:

Neural Network Architecture

Model Size: 48 million parametersInput Features:

• User features (1000+ dimensions)
  • Follow graph
  • Engagement history
  • Demographics
  • Interests
• Tweet features (500+ dimensions)
  • Content embeddings
  • Author information
  • Engagement metrics
  • Freshness
• Context features
  • Time of day
  • Device type
  • Location

Predicted Metrics:

• Probability of engagement (like, retweet, reply)
• Dwell time
• Negative actions (report, mute, block)
• Follow probability

Model Training:

• Trained on billions of examples
• Multi-task learning
• Regular retraining (daily)
• A/B testing for improvements

Ranking Signals

Engagement Predictions:

• Like probability (weight: 1x)
• Retweet probability (weight: 2x)
• Reply probability (weight: 3x)
• Profile click probability
• Video watch time

Content Quality:

• Author authority
• Tweet freshness
• Media richness (images/videos)
• Link quality

User Preferences:

• Historical interactions
• Topic interests
• Network similarity
• Explicit feedback

Twitter Blue Boost

Subscribers to Twitter Blue receive ranking boosts:Boosting Strategy:

• 2x boost for verified subscribers
• Applied after scoring
• Helps surface quality content
• Controversial but revenue-driven

Implementation:

• Multiplicative boost to score
• Configurable weight
• A/B tested extensively

​

Stage 4: Filtering for Diversity

Goal: Achieve author and content diversity

Diversity Rules

Author Diversity:

• Limit tweets from same author
• Space out tweets from followed accounts
• Mix in-network and out-of-network

Content Diversity:

• Avoid similar topics in sequence
• Mix media types (text, images, videos)
• Balance trending vs evergreen content

Temporal Diversity:

• Mix recent and older tweets
• Balance real-time and algorithmic content
• Ensure some recency

Techniques:

• Sliding window deduplication
• Topic clustering
• Greedy selection with constraints
• Re-ranking for diversity

​

Stage 5: Mixing with Other Content

Final Timeline Composition: Mixing Strategy:

• Interleave ads at optimal frequency
• Insert “Who to Follow” suggestions
• Add trending topics
• Include promoted content
• Balance monetization and user experience

​

Performance Optimization

To achieve the 1.5-second goal: Parallelization:

• Stages run in parallel where possible
• Distributed scoring across GPU clusters
• Asynchronous processing

Caching:

• User embeddings cached
• Tweet features pre-computed
• Popular tweets pre-ranked

Infrastructure:

• Low-latency data stores
• Edge computing for regional users
• Predictive pre-fetching

​

Real-Time Tweet Delivery

​

Fanout Architecture

When a user posts a tweet: Fanout-on-Write (for small followings):

1. Tweet posted to database
2. Immediately pushed to followers’ timelines
3. Cached in Redis/Pelikan
4. Fast reads at the cost of write amplification

Fanout-on-Read (for large followings):

1. Tweet posted to database
2. Followers fetch dynamically when reading timeline
3. Reduces write amplification
4. Used for celebrities with millions of followers

Hybrid Approach:

• Small/medium accounts: fanout-on-write
• Large accounts: fanout-on-read
• Threshold-based decision
• Optimizes for both read and write performance

​

Streaming and Messaging

​

Apache Kafka

Twitter heavily uses Kafka for: Use Cases:

• Tweet stream processing
• Real-time analytics
• Event sourcing
• Cross-datacenter replication
• Feed generation

Scale:

• Billions of messages daily
• Hundreds of clusters
• Petabytes of data
• Sub-second latency

​

Stream Processing

Apache Storm / Heron:

• Real-time computation
• Trend detection
• Spam filtering
• Real-time counters

Processing Patterns:

• Event time processing
• Windowed aggregations
• Stateful processing
• Exactly-once semantics

​

Key Architecture Decisions

​

1. Custom Infrastructure

Twitter built many custom solutions:

• Manhattan: Distributed database
• Pelikan: High-performance cache
• Finagle: RPC framework
• Heron: Stream processing (Storm successor)

Reasoning:

• Specific performance requirements
• Scale beyond existing solutions
• Optimize for Twitter’s access patterns
• Full control over performance tuning

​

2. Hybrid Fanout Strategy

• Balances read and write performance
• Handles both typical and celebrity users
• Reduces infrastructure costs
• Maintains real-time experience

​

3. Machine Learning at Scale

• 48M parameter ranking model
• Billions of training examples
• Real-time inference
• Continuous learning and improvement

​

4. Multi-Datacenter Architecture

• Active-active across regions
• Eventually consistent model
• Optimized for availability
• Graceful degradation

​

Challenges and Solutions

​

Lessons Learned

Custom vs. Off-the-Shelf:

• Twitter built custom solutions (Manhattan, Pelikan, Finagle) when needed
• Used open-source where appropriate (Kafka, Mesos)
• Balance between build and buy

Real-Time at Scale:

• Multiple stages of filtering/ranking
• Parallelization and caching critical
• GPU acceleration for ML inference
• Sacrifice perfect consistency for availability

ML-Powered Recommendations:

• Massive investment in recommendation systems
• 48M parameters trained on billions of examples
• Continuous experimentation and improvement
• Balance engagement with user experience

Social Graph Complexity:

• Hybrid fanout strategy essential
• Different approaches for different user types
• Real-time updates vs. batch processing tradeoffs

​

Scale Statistics

• 400+ million monthly active users
• 500+ million tweets processed daily
• 1.5 seconds to generate personalized timeline
• 48 million parameters in ranking model
• 500 million → 1,500 candidates filtered in Stage 2
• Multi-region active-active architecture

​

References

• Twitter Engineering Blog
• Twitter Open Source
• Twitter Recommendation Algorithm (Open Source)
• Finagle RPC Framework