System requirements

Functional:

1. User can tweets.
2. User can search tweets based on text.
3. When searching, user's following's tweets should return first.

Non-Functional:

1. High availability
2. Eventual consistency. To achieve high availability, it's ok to wait for two or three seconds to allow new tweets to become searchable.
3. Security.
4. low latency.

Capacity estimation

Assume 1B daily active users for twitter.

Read QPS: 1B / 100k = 10k

peak read qps have twice traffic: 2 * 10k = 20k

Assume 1% user post 10 tweets per day.

Write QPS: 1B * 1% * 10 / 100k = 1k

peak write QPS have twice traffic: 2 * 1k = 2k (high write throughput)

Storage usage estimation:

Assume one tweet has average of 10kb storage. 90% tweets are text tweets. 10% tweets are image/video tweets.

Daily storage: 1B * 1% * 10 * 10kb = 1TB

Yearly storage: 400TB

We need 3 replica for the db. So yearly storage: 1.2PB

API design

GET searchTweets(userId, text)

return the list of tweets

POST postTweet(userId, tweetInfo)

return success/error

Database design

NoSQL database to store the tweets information. I choose NoSQL database because the tweets information is flat data and the write throughput put is very high. NoSQL db could handle high write throughput.

Tweets Table

TweetId (primary key)

tweet content

tweet media

tweet user (reference key to user id)

Document DB is used to store text information for tweets. Document DB is easy to do multiple index on the text information for fast search.

High-level design

Please see the diagram

Request flows

Please see the diagram

Detailed component design

Indexer:

Create indexes when a new tweets created and saved into NoSQL DB and Document DB. The indexer could be saved in search tweets service.

Search tweets service:

Search tweets service is the search engine. I can use elastic search to search the recalculated indexes.

Cache layer:

Cache layer could be put in front of NoSQL DB, Document DB and Search tweets service to speed up the response time.

Write tweets service:

When new tweets created, the tweets will be put into message queue to prevent too many tweets write request arrived at the same time. The message queue works as a buffer because the system is write heavy. The design prioritize availability over consistency. The new tweet doesn't need to searchable immediately. We choose eventually consistency to ensure high availability and low latency.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Our non-functional requirements for the proposed twitter system design are scalability, fault tolerance, availability, and low latency. Let’s discuss how the proposed system fulfills these requirements:

1. Scalability: The proposed system is scalable to handle an ever-increasing number of users. The required resources, including load balancers, web servers, and other relevant servers, are added/removed on demand.
2. Fault tolerance: The replication of data consisting of theater, movie, seat, ticket database tables makes the system fault-tolerant. Moreover, the redundant resources are always there to handle the failure of a server or its component. Monitoring service is used to enhance reliability by continuously observing system health, detecting issues early, providing insights for optimization, and assisting in timely incident response.
3. Availability: The system is highly available by providing redundant servers and replicating data on them. When a user gets disconnected due to some fault in the server, the session is re-created via a load balancer with a different server. Moreover, the data (users metadata, posts, and newsfeeds) is stored on different and redundant database clusters, which provides high availability and durability.
4. Low latency: We can minimize the system’s latency at various levels by:

• Geographically distributed servers and the cache associated with them. This way, we bring the service close to users.
• Using CDNs for frequently accessed media content.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?