Define use cases and constraints
Use cases (in scope)
- User posts a tweet; the service pushes it to followers (push notifications + emails).
- User views the user timeline (own activity).
- User views the home timeline (activity from people they follow).
- User searches keywords.
- Service has high availability.
Out of scope
Firehose/stream pushes, visibility stripping (hide @reply, hide retweets), analytics.
Constraints and assumptions
- Traffic is not evenly distributed.
- Posting a tweet must be fast; fan-out must be fast (unless the user has millions of followers).
- 100 million active users, 500 million tweets/day, ~10 fan-out deliveries per tweet.
- 250 billion reads/month, 10 billion searches/month.
- Ingesting tweets is write-heavy; viewing timelines and search are read-heavy.
Usage
- ~10 KB per tweet → 150 TB new content/month, 5.4 PB in 3 years.
- 100 thousand reads/s, 6,000 tweets/s, 60 thousand fan-out deliveries/s, 4,000 searches/s.
Sketch the high-level design
- Entry
The client reaches a web server and read, write, and search APIs.
- Write fan-out
Tweet info, fan-out, and user-graph services populate timelines.
- Read composition
Timeline reads join cached IDs with tweet and user information.
- Storage and search
Memory cache, SQL, object storage, and search support their respective data paths.
Reads combine timeline IDs with tweet and user data; writes prepare fan-out.
How to read this model
A publishing sorter beside timeline and user-graph archives. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Define the core components
Post a tweet
- Client → Web Server (reverse proxy) → Write API.
- Write API stores the tweet in the user's timeline on SQL.
- Write API calls the Fan Out Service:
- Queries the User Graph Service for followers (in a memory cache).
- Stores the tweet in each follower's home timeline in a memory cache: an O(n) operation (1,000 followers = 1,000 inserts).
- Stores the tweet in the Search Index Service.
- Stores media in an Object Store.
- Uses the Notification Service (with a queue) to notify followers asynchronously.
View the home timeline
- Timeline Service reads tweet ids from the memory cache: O(1).
- Queries Tweet Info Service and User Info Service with a multiget: O(n).
View the user timeline
Reads the user's own tweets from the SQL database.
Search keywords
- Search API → Search Service: parse, remove markup, tokenize, fix typos, normalize, build boolean query.
- Query the Search Cluster (Lucene): scatter-gather across servers, then merge, rank, sort, and return.
Scale the design
- Entry
DNS, CDN, a load balancer, and web servers precede read, write, and search APIs.
- Timelines
Timeline, fan-out, and user-graph services prepare appropriate cached feed data.
- Search and notification
A search cluster and notification queue support independent demand.
- Read storage
Memory cache, SQL replicas, and object storage supply feed data. Celebrity accounts can use a read-time merge policy.
The example can merge celebrity posts on read to avoid excessive write fan-out.
How to read this model
An expanded publishing sorter beside timeline and search cabinets. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
- The Search Cluster keeps tweets in memory for low latency.
- SQL read replicas may not handle all cache misses → federation, sharding, denormalization, SQL tuning, and consider moving data to NoSQL.
Additional talking points
- Caching placement and update policy: see cache.
- Asynchronism for notifications: see asynchronism.