Theme

Interactive diagram · architecture

Design the Twitter timeline and search

Design the Twitter timeline and search The Twitter design routes a client through DNS, CDN, load balancing, web servers, APIs, timeline, fan-out, search, cache, SQL databases, notifications, and object storage. Design Twitter Diagram after donnemartin/system-design-primer · CC BY 4.0 Client DNS CDN Load Balancer Web Server Write API Fan OutService User GraphService Memory Cache SearchService NotificationService SQL WriteMaster–Slave ObjectStore 1 · Post a tweet Read API Tweet InfoService TimelineService User InfoService SQL ReadReplicas 2 · View home timeline 3 · View user timeline Search API4 · Search keywords
✕

1 · Post a tweet

The write path stores the tweet, fans it out to followers, indexes it, stores media, and notifies followers.

✕

2 · View home timeline

The read path gets timeline ids from cache and enriches them with tweet and user information.

✕

3 · View user timeline

The read API retrieves the user timeline from the SQL database.

✕

4 · Search keywords

The search API parses the query and asks the search service for ranked results.

✕

Client

What it is

The person or program making a request.

Its job here

It resolves DNS, can fetch static content from CDN, and sends requests to Load Balancer.

In the primer

Domain name system →

✕

DNS

What it is

DNS translates a domain name to an IP address.

Its job here

It receives the client lookup and directs the client to the service address.

In the primer

Domain name system →

✕

Load Balancer

What it is

A load balancer distributes requests across computing resources.

Its job here

It receives client traffic and sends it to Web Server instances.

In the primer

Load balancer › Horizontal scaling →

✕

Read API

What it is

An application API that handles timeline reads.

Its job here

It receives requests from Web Server and asks Timeline Service or SQL Read Replicas for timeline data.

In the primer

Application layer › Microservices →

✕

Write API

What it is

An application API that handles tweet writes.

Its job here

It receives work from Web Server, stores the tweet in SQL Write Master–Slave, and contacts Fan Out Service.

In the primer

Application layer › Microservices →

✕

Timeline Service

What it is

A service that builds home timeline results.

Its job here

It receives Read API requests, reads ids from Memory Cache, and calls Tweet Info Service and User Info Service.

In the primer

Cache › Application caching →

✕

Fan Out Service

What it is

A service that distributes a tweet to followers.

Its job here

It receives the new tweet from Write API, queries User Graph Service, writes follower timelines to Memory Cache, indexes search, and starts notifications.

Trade-off

Users with millions of followers can take minutes to finish fanout.

✕

User Graph Service

What it is

A service that finds a user’s followers.

Its job here

Fan Out Service queries it, and it uses Memory Cache for follower information.

In the primer

Cache › Application caching →

✕

User Info Service

What it is

A service that supplies user details.

Its job here

Timeline Service calls it with a multiget to enrich user ids.

✕

Memory Cache

What it is

An in-memory store for timeline and follower data.

Its job here

Timeline Service reads it, while Fan Out Service and User Graph Service update or query it.

In the primer

Cache › Application caching →

✕

Search Service

What it is

A service that parses and queries keyword search.

Its job here

It receives Search API queries and new tweets from Fan Out Service, then returns ranked search results.

Examples

  • Lucene
✕

Notification Service

What it is

A service that sends push notifications.

Its job here

Fan Out Service calls it to notify followers asynchronously through a queue not pictured.

In the primer

Asynchronism › Message queues →

✕

SQL Read Replicas

What it is

Replicas serve database reads after changes are copied from the writer.

Its job here

Read API uses them for cache misses and user timeline reads.

In the primer

Database › Master-slave replication →

✕

SQL Write Master–Slave

What it is

A SQL writer stores tweets and replicates changes.

Its job here

Write API sends new tweets here; user timeline reads use the database data.

In the primer

Database › Master-slave replication →

✕

Object Store

What it is

Storage for media such as photos and videos.

Its job here

Write API stores media here, and CDN can serve that media to Client.

←/→ step · Space play/pause · R replay · Home/End jump

Detail · follows playback, or click any box or step to pin it

Click any box for an explanation, or use Next or Play to walk through the four steps.

1 · Post a tweet

The Write API stores a tweet, then the Fan Out Service builds followers’ home timelines, indexes search, stores media, and sends notifications.

The post path favors fast writes and fanout.

2 · View home timeline

Timeline Service reads timeline ids from Memory Cache, then multigets tweet and user information.

The home timeline favors fast reads.

3 · View user timeline

Read API retrieves the user’s own timeline from the SQL database.

This path reads the user’s stored tweets.

4 · Search keywords

Search API forwards a parsed query to Search Service, which queries the Search Cluster and returns ranked results.

The search path is read-heavy.