System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. Users should be able to create posts with images and videos.

2. Users should be able to follow/unfollow users.

3. Users should be able to see customized newsfeed encomposing the posts from their followers.

Non-Functional:

List non-functional requirements for the system...

1. Low latency, posts shall take no more than 5 seconds to reach each user.

2. Scailability, the database should be able to handle a growing user base and number of posts.

3. Availability, the system should achieve 99.9% uptime

Capacity estimation

Estimate the scale of the system you are going to design...

2 billion users * 10 posts / seconds in a day

QPS = 2^9 * 10 / 10^4 = 10^6 * 2 = 2,000,000

Each post can be about 10MB

Each second

10mb * 10 posts * 2^6 per user * 2 scale factor = 2^8 = about 2 GB a second

API design

Define what APIs are expected from the system...

returns a post for a user

https://getPost/post_id (GET)

{post_id: 1)

returns all posts for a search query

https://getPosts/query (GET)

{query: cars}

creates a post

https://createPost/user_Id (POST)

{user_id: 1, media_content: blob, text_content: text}

follow or unfollow a user

https://follow/user_id/following (POST)

{user_id: 1, following: true}

get a news feed for a user

https://getNewsFeed/user_id (GET)

{user_id: 1}

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

noSQL Blob storage

media_table

media_id: string

media_content: blob

user_id: bigInt (FK)

post_id: bigInt (FK)

SQL

users_table

user_id: bigInt (PK)

user_name: string

SQL

followers_table

id: bigInt (PK)

follower_id: bigInt

user_id: bigInt (FK)

SQL

posts_table

id: bigInt (PK)

user_id: bigInt (FK)

media_url: string

text_content: string

SQL

news_feed_table_sql

id: bigInt (PK)

user_id: bigInt (FK)

noSQL

news_feed_table_nosql

id: bigInt (PK)

user_id: bigInt (FK)

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

1. Client creates a post and sends the https://createPost/user_Id request to the Load Balancer

2. The Load balancer redistributes the request to the approriate Service Discovery service depending on load capacity

3. The Service Discovery service sends authenticates the user with the user service

4. The user service sends the request back to the service discovery

5. The service discovery sends the request to the post service

6. The post service sends the request to the post cache.

7. The post cache does not have this content, the cache implements read through cache, it sends the request to the DB.

8. The post DB logs the post in the database table and sends the request back to the post cache

9. The post cache stores a record of this post for future requests with a time to live of 24 hours because it supports the read through cache protocol and sends the result back to the post service

11. The post service sends the request back to the service discovery

12. The service discovery sends the request back to the load balancer

13. The load balancer sends the request back to the client.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

1. Caching. All of our caching services perform read through cache. This means if the data is in the cache we return that immediately, otherwise the cache service retrieves the information from the correct DB. The correct DB sends the information back to the cache service. The cache service stores this information for future request with a time to live rule of 24 hours. The Databases will emit a message to the cache layer to invalidate the content that is store if updates are made to posts. This will ensure the content is always up to date in the cache layer.

2. The news feed service retrieves the news feed for a particular user. If the user is a celebrity user we use the News Feed Cache noSql and the News Feed noSQL DB. This is because the celebrity user may have millions of users and generating an accurate news feed would require checking every followers posts, as a result we use noSQL for optimal performance and update the cache of only the celebrities when new posts are created so they have fast access to their news feed. For normal users we utilize the news feed cache SQL and the news feed SQL DB. The relational SQL tables are not as fast as the noSQL databases but this is okay since these users may not have many users to iterate over when generating their news feed.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

1. The news Feed Service uses two different databases for different users. This is because a small amount of users may have much more users than others and as a result it would be beneficial to use a noSQL database to help with performance and keeping its cache up to date. If we did this for all the users we could waste resources for individuals that do not have as many users. We utilize a traditional relational SQL database for the majority of users. This is because relational databases are easier to deal with when querying other tables, we also don't update the cache as frequently as if the user was a celebrity. This is for performance reasons, we don't want to spend resources by updating a cache for a user that rarely logs into our application.

2. Databases. We use many databases since we handle billions of users a year. This allows us to scale each database individually and allows us to achieve better reliability and works on our goal of scailability. We use a media_content database just for photos and videos since these pieces of data are so large they warrant their own database, we don't want them clogging up our other databases. We store the url of the media in our post database so they can easily get the content from the media database. The media database is noSQL since we only need the url, we don't need to query many other tables to return the result. SQL relational databases are good for querying other tables and joining the result, however they're slower.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

1. We have not gone in depth on each database, but one bottleneck would surely be the data being to large for each one. Partitioning each database we have would be essential to support the amount of users Facebook has. We should include sharing keys in each DB and ensure that range scan queries can be achieved.

2. Stale reads or stale data. Since we're utilizing many caches we will likely run into an issue where users will experience receiving stale data. Meaning the data being retrieved from the cache would be stale or out of date. We should ensure caches receive database messages posts that are updated to ensure the cache stays up to date.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

1. Go in depth on the database architecture that is being used. Since this is Facebook ensure we have different regions and in each region we have this architecture laid out in the design I've implemented. Use leaderless replication per region for optimal performance. We choose leaderless over single leader replication since many of those implementations use two way commit, and two way commit could be slower since we need to hear from all nodes in the region/regions.

2. The media service can be split in two. A video service and a image service. The video service can implement transcoding have additional databases and caches for optimal user and architecture experience. Since photos are not nearly as complex as videos having a separate database for those data types would allow be a good architecture design when it comes to islolating and separating modules, this supports decoupling which is easier to deal with long term because it allows us to easily target fixes or certain implementations to parts of our architecture without it affecting other parts...which could create regressions and hardaches.