System requirements

Functional:

• users can send posts which will be fan out to their followers
• users can get all the posts from their followings in the reverse chronological order

Non-Functional:

• performance: low latency, high throughput
• scalability
• high availability

Capacity estimation

Assume we have 1B users and 200M DAU. Each DAU make 2 posts daily and retreives 10 times a day.

read: 23k QPS

write: 5k QPS

API design

CreatePost

• request:
  • user_id
  • created_at
  • content
• response:
  • status

GetNewFeeds

• request:
  • user_id
  • last_fetch_id
  • feed_num
• response:
  • list of content

Database design

Users

• user_id(pk)
• email
• birthday
• followers
• following

Posts

• post_id(pk)
• user_id

High-level design

Request flows

• In the write path, when a user create a post,
  • the web server first send that to post server and then write to the datastores
  • the web server calls fanout server, which gets the follower-following relationship and write the <user_id, post_id> into the message queue
  • the fanout workers pull the data from message queue and write that into the datastore
• In the read path, when a user wanna get their posts
  • the fanout server pulls their news feed from their datastores

Detailed component design

Push or Pull model

Push model is that when the post is made, it will be written to all the followers. Pull model is that the new feed is built only when the users really get their feed.

Push over Pull

• low latency when pulling

Pull over Push

• storage and computation save
• no hotspot problem(celebrity), the servers got overwhelmed

Ideally, we can use the push + pull hybrid, which means we do pull model for the most users but for the celebrities, we does push for their followers.

Cache

All the datastores can be cached with in-memory cache.

Also, we can leverage CDN for media data to improve latency.

Datastore Choice

We will use non-relational DB as

• we need horizontal sharding which is better supported on non-relationship
• this is write-heavy qps which is better performant in non-reltaionship
• we don't support ACID and eventual consistency is accepted

Trade offs/Tech choices

We have discussed several tech choices above including

• push vs pull
• DB choice

Failure scenarios/bottlenecks

• The web server can be a bottlenecks for a high load. We can
  • add API rate limiting on it or LB
  • horizontally scale it

Future improvements

• we can move those in-active users to push-based as well.