Requirements

Functional Requirements:

• Users can find tweets by text, time range, and/or author.
• Users can create & read tweets.
• Users can like tweets.

Non-Functional Requirements:

• The system should scale up to support 50M DAU, 200M new tweets per day, and 500M search queries per day
• The system should have low latency (<100ms for tweet search)
• The system should have high availability, and eventual consistency is enough
• The system should have fault tolerance to guarantee data durability even with node or partition failure

API Design

POST /tweet {

"user_id": "456",

"create_time": datetime,

"title": "XXXX",

"content": "YYYYY",

} -> insert a new tweet in the database, and return the unique id

GET /tweet?id=123

-> return the specified tweet and display it to the user

GET /tweet?keywords=abc+efg&author=XXX&time_range=YYYY_ZZZZZ

-> return a list of tweets matching keywords, time range, and/or author.

POST /like {

"tweet_id": "123",

"user_id": "456",

"create_time": datetime,

} -> create a new like for the given tweet.

Database Schema:

User {

"id": str - primary key

"name": str - index,

"create_time": datetime,

"email": str,

"tweet_list": list of tweets }

Tweet {

"id": str - primary key

"create_time": datetime,

"title": str - inverted index,

"content": str - inverted index,

"likes": list of user ids }

With 200M new tweets per day, the total database storage is 200M * 2MB * 365 * 3 = 400PB in 3 years.

High-Level Design

Client:

1. Send requests to create/read tweets, or like any tweet
2. Send requests to search for any tweet based on author, text, or time range

API gateway:

1. Perform request validation, authentication, and load balancing
2. Route different requests to corresponding micro-services

Tweet server:

1. Handle requests to create new tweet (insert into database), read tweet (retrieve from database based on tweet id), and like tweet (insert user id to tweet like list)
2. Search tweets with text by inverted index (title and content)

Elasticsearch:

1. Serve a separate search engine, especially for text search
2. Use a master node (keep monitoring other nodes and maintain system functionality), ingest nodes (process test documents and create inverted index), data nodes (store inverted index relations, keyword -> tweet id), and coordinate nodes (route data and requests, merge search results from data nodes)

Cache and CDN:

1. Cache popular tweets and frequently accessed search results to reduce latency, using LRU and TTL strategies to remove stale data
2. Use CDN to cache popular tweets across different user regions by deploying edge servers to save data travel time

Detailed Component Design

Elasticsearch:

1. Use query normalization for search text, for example, tokenize, remove stop words, and stem.
2. Differentiate between individual keywords and phrases by keeping the exact phrase as an n-gram, as use it as an index.
3. When a tweet is created, it is first stored in the primary database and then added to an inverted index asynchronously. The fresh posts will appear in the search results, in a delay of up to a couple of minutes.
4. For time-filtered queries, we can implement inverted index from keyword to tweet IDs, along with timestamps, so that we can easily apply a time filter on the search result.

Cache and CDN:

1. Cache popular tweets and frequently accessed search results to reduce latency, using LRU and TTL strategies to remove stale data
2. Use CDN to cache popular tweets across different user regions by deploying edge servers to save data travel time

Scalability:

1. Shard tweet servers by region, and replicate to avoid single point failure. Also shard the database by tweet id to improve search performance, and replicate to guarantee high availability and fault tolerance.
2. Partition the like counter across multiple shards. Each shard can handle a portion of the writes, and when a user likes a tweet, the request can be routed to one of the shards, allowing for concurrent updates.
3. Additionally, consider employing a write-behind caching mechanism. When a user engages with a tweet, you can increment the counter in memory first, which provides immediate feedback to the user. The actual count can then be updated asynchronously in the database. 

Fault tolerance:

1. Downgrade service for cache outage, by retrieving query result directly from the database, but should allow high latency (should apply rate-limiting or throttling to avoid crash or cascading failure), or we can still serve stale/smaller set but usable data to users while waiting for the cache to come back to work.
2. Implement a timeout mechanism for very long and complex search queries, by limiting the max time threshold and also max intersection number.
3. Perserve the latest snapshot and logs for recent database operations, and during index corruption or database outage, we can still restore the index from the most recent snapshot and then apply the log to replay changes.