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.

Client :- Client is our end user, any user in this world will be our client.

Load balancer :- whenever any request will come from client first it will go to load balancer which will distribute the request.

API Gateway:- Our api gateway will be act as single entry point where request will be routed to particular services which will handle the request purpose. Here we can add our security, circuit breaker, rate limiting, SSL , TLS.

API Server :- API server is nothing but our application server which runs our service code means our app data controller, service, repository.

Database:- To maintain or store data we have implimented both SQL and noSQL , SQL is for fixed schema data, and noSQL will be flexible schema data.

Cache :- Here we have added a cache , which will optimize our performance. let say we will be showing topK data all the time when our client open his app that time it will get data from redis instead of hitting always to Database, which will increase the DB load.

Communication - whenever request come from client request will go to load balancer, load balancer then distribute the request and forward that request to API Gateway, API gateway then route the request to particular service in our api server. api server talk to first cache, if data is not there then hit the db.

Home Feed Strategy :-

The Fan-Out :- When a user tweets, a Fan out worker pushes the tweetId into Redis Home Timeline of all active follwers.
Celebrity handling :- To mitigate "hot key" issues where a celebrity has 100M followers, we use a hybrid model. we do not fan out celebrity tweets. Instead, when a follower request their feed, we pull the celebrity's recent tweets from Database and merge them with the pre-computed redis feed at read-time.

Cache Capacity & Resilience:-

Cache Estimate: if we store the top 200 tweetIDs(8 byte each) for 200M active users : 200M * 00 * 8byte = 320 GB of RAM. Given redis overhead, we would provision a 500GB redis cluster.
Cache Miss/cold start: if a user is inactive and their cache is evicted, the timeline service triggers a background "Cache redbuild" by querying the SQL db for the users follows and fetching the latest 200 tweets.

Ranking & Pagination:-

Ranking : Initially tweets are ordered chronologically. To scale, we use a scoring service that weight tweets based on Likes, Recency and Follower count before injecting them into the redis feed.
Consistent Pagination: We use cursor based pagination (ex: max_id = tweet_id). this ensure that if a user scrolls while 100 new tweets are posted, they wont see the duplicates, as the cursor stays achrored a specific TweetID rather than a page number.

Reliability and Spike Mitigation:

kafka for spikes: During high activity events kafka acts as a buffer, if the fan out workers lag, the system remain responsive, and feeds are updated eventually (Eventual Consistency) rather than crashing the API.
Circuit Breakers: We impliment Resilience4j on the tweet service. if the DB or s3 becomes unresponsive, the circuit opens to prevent a cascading failure, returning a "Service Unavailable" message quickly rather than letting requests hang.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10