System requirements

Functional:

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

Users can post tweets up to 300 characters including alphanumeric and emojis

Users can follow and unfollow other users

The number of likes should be visible on a tweet

Users can post comments on tweets

Users can view comments on tweets if they click to load comments

Non-Functional:

List non-functional requirements for the system...

Can handle up to 500,000 concurrent users

The response time for fetching the user's home page should be under 500ms for the first five tweets.

Eventual consistency for data propagation

Reliable, users can trust that their tweet will get created when they submit it.

Capacity estimation

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

500,000 concurrent users

3 million total users each year

Average number of tweets per user is 10 per year

30 million total tweets each year

Global user base

Average tweet size is 100 characters

API design

Define what APIs are expected from the system...

get tweets

create tweet

update tweet

delete tweet

create like

delete like

get comments

create comment

update comment

delete comment

create user

get user

update user

delete user

log in

log out

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

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...

The front-end code for web pages is presented by a cluster of web servers. That content is cached with CDN service to distribute the content.

There's another cluster of backend servers that runs the API functions and communicates with the databases.

Everything has redundancy to provide high availability.

There's a load balancer to distribute load effectively.

There's a firewall to ensure only permitted traffic is allowed.

Authentication required (middleware)

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...

User requests to view home page. That is cached data provided from CDN. The CDN syncs content from the web server.

User enters data in form to create a new tweet. Request is sent through load balancer and firewall to a queue on backend servers.

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...

Trade offs/Tech choices

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

Cloud-hosted preferred for dynamic scaling and load balancing

CDNs to reduce latency, preferable over global consistency

Failure scenarios/bottlenecks

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

Large spikes in concurrent users

Increasing storage requirements over time

Future improvements

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

Consider removing inactive users and their tweets after some period of time has passed (years)

Dynamic scaling and load balancing