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

High-level design

Please see the diagram

Request flows

Please see the diagram

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

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