Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

# Tweet Service

## Real Time Tweet Request Handling

Implement the tweet endpoint and manages the tweet table and like table.

Uses the Message Queue to quickly send an ack to the user when posting and liking, shortening the response time of potentially compute heavy process (insert, cache invalidation for feeds of the people who follow the user). Also adding some fault tolerance (if the server crashes after sending an ack the message persists and can be handled by another server instance)

## Offline Message Queue Handling

Consumes the Messages from the Message Queue and handles their jobs asynchronously. That means Database Updates, User Feed Cache Invalidation, etc.

## Cache Handling

Uses the cache in 2 main ways:

Singular key for general popular tweets, sorted by a linear combination of tweet likes and the posting user follow count, that is refreshed every minute.

Second key for personalized user feed, that gets populated upon user login for quick viewing of followed account's tweets.

Should support sharding for

# Edge Cases Handling

Heavy System load - The cache adds some read tolerance, message queue gives a buffer for Database writes, Stateless services allows for dynamic autoscalling. If traffic spikes and some servers go down, the asynchronous method of message handling perserves consistency.
Viral Tweet - a fast growing tweet will be added to the popular tweets cache at most a minute after passing the threshold. In practice, the message queue makes tweets slower to grow than the users may expect.

# Tradeoffs

Message queues and caches are expensive, especially at scale.
Could have improved performance by sacrificing consistency by saving like count at the tweet table (incrementing on like, decrementing on dislike)

Submissions

Displaying Solutions with Scores Ranging from 1 to 10