Newsfeed

May 22, 2022 7:00 PM PDT

---

This document summarizes a mock system design interview focused on designing a newsfeed system. The interview covered functional and non-functional requirements, system architecture, database design, and potential scalability challenges. The discussion included various technical aspects such as service interactions, data storage solutions, and performance considerations.

Interview Details

• Interviewer: [Redacted]
• Interviewee: [Redacted]
• Level: L5 (Senior)
• Duration: 45 minutes
• Topic Covered: Design Newsfeed
• Drawing Tool Used: Excalidraw

Requirements

Functional Requirements

• Users can see newsfeed.
• Users can post newsfeed content: text, images, and videos (focus on text and images first).

Non-Functional Requirements

• Assume 100,000 users.
• Each user posts approximately 2 tweets per day.
• Daily Active Users (DAU): 10,000 users.
• System stability and reliability: 24/7.
• Data throughput: 20,000 tweets per day, resulting in approximately 200 GB of data daily.

Non-Requirements

• Login/logout functionality.
• User following features.

System Design

Database Architecture

• MySQL: Used for storing feed information, user posts, follower relationships, and timelines.
• NoSQL (MongoDB): Used for storing media files (images, text, video).

Data Flow

1. Posting a Tweet:

   • The tweet service saves content to MongoDB.
   • The service interacts with the user service for authentication.

2. Reading the Feed:

   • The friendship service identifies followers to retrieve new feeds.
   • The newsfeed service aggregates tweets based on the timeline.

Service Interaction

• Friendship Service: Manages follower relationships.
• Tweet Service: Handles tweet creation and retrieval.
• Newsfeed Service: Acts as a broker, aggregating data from the tweet service and friendship service.

API Design

• Endpoints:

  • getTweets/Id=123/pageNo=1
  • postTweets/getTweets/page/No=1

• Pagination: Managed by the newsfeed service, which requests data from the tweet service based on pagination parameters.

Scalability Considerations

• As user count increases (e.g., from 100,000 to 100 million), potential bottlenecks may arise in various services.
• Strategies for scaling include:
  • Space distribution and sharding.
  • Caching for frequently accessed data (e.g., celebrity posts).
  • Asynchronous services for tweet persistence.

Notification Service

• Monitors users' followings to notify them of new posts.
• Can push notifications to offline users when a celebrity posts.

Feedback Summary

Interviewer Feedback

• The interviewee should have clarified functional requirements more thoroughly.
• More time should have been spent discussing the trade-offs between push and pull mechanisms.
• The architecture diagram needed to be clearer, and database table names should have been included.
• The discussion on scaling should have been more progressive, considering the implications of increasing QPS.

Interviewee Reflection

• The interviewee felt interrupted during the discussion of architecture.
• They believed the low QPS provided was a trick question and did not align with typical expectations.
• They acknowledged the need for a deeper discussion on caching and queuing mechanisms as user load increases.

Key Dimensions for Consideration

• Normal users vs. celebrities.
• Post creation and viewing mechanisms.
• Strategies for handling high user loads and ensuring efficient data retrieval.

Conclusion

The interview highlighted the complexities involved in designing a scalable newsfeed system, emphasizing the importance of clear requirements, effective service interaction, and thoughtful consideration of scalability challenges.