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. API Server
  5. Database
  6. Cache (Redis Cache)




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.