Requirements


Functional Requirements:


  • Allow users to tweet messages up to 140 characters.
  • Enable users to follow other users.
  • Allow users to like tweets from other users.
  • Display tweets from followed users in the home feed.
  • Show top K popular tweets in the home feed based on likes and followers.



Non-Functional Requirements:


  • List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
  • At any time user should be able to tweet and see others tweet in his/her feed.
  • Low Latency :- User should be able to tweet within 3-5 sec max, user should be able to refresh his/her home feed in 2-3 sec.
  • Scalability:- The system must handle a high Read-to-Write ratio. We will implement Database Sharding by UserID to distribute data load and a Redis-based Fan-out service to pre-compute timelines. To handle "Celebrity" accounts, we will use a Hybrid Pull/Push model to prevent cache exhaustion. Horizontal scaling will be managed via a Load Balancer (Nginx/HAProxy) across stateless application servers.
  • Reliability :- Even if any fault or any issues system should work consistently over a specific time.
  • Availability: The system should always be available to serve user request. our system should be resilient to handle such request. we will implement fault tolerance, resiliance4j, auto-scaling like HPA, load balancer which distribute the request to other idle server in peak time. we should impliment Disaster Recovery using replicas, aws availability zones.


API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

  • POST - /user/tweet/createPost

Request :- {"content": "tweet details content", "contentId":uniqueNumber, "maxChar": 500}

Response: - {200}

  • POST - /user/followOthers

Request:- {"toFollowUserName": "otherAccountUserName", "toFollowId":"followId"}

Response:- {200}

  • POST - /user/likeTweet

Request:- {"tweetId": "otherUserContentId"}

Response:-200

  • GET - /tweet/homeDisplay
  • GET - /tweet/getTopKTweets

Request:- {"topKno": 10}


High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Here are my components in this HL Design :-

  1. Client
  2. Load balancer
  3. API Gateway
  4. CDN (Global CDN)
  5. Microservices
  6. TweetService
  7. FollowService
  8. TimeLineService
  9. Kafka Queue
  10. FanOutService
  11. Database
  12. Cache (Redis Cache)
  13. AWS S3 for Media(Image/Video/Audio)


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.

Write Path :-When client send request with tweet it will come to loadbalancer, then load balancer distribute the request to API gateway , api gateway request that request to tweet service, Tweet service process that request and store it in S3 or Database according to the request.

Read Path :- Once Api gateway receive the request , it will route the request to TimeLine Service, Then timelineservice process the request and send it to cache , cache will response with data if it is static data then get it from CDN.





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.