System requirements

Functional:

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

The users can capture a screenshot, store it, and send it.

The users can download their own screenshots made earlier

The users can assign tags to a screenshot.

Users can share screenshots with their friends to view them.

The users can change the size of images and its properties before uploading.

The users can remove their screenshots.

The uses can download the platform-dependent client application to capture the screenshot.

Non-Functional:

List non-functional requirements for the system...

We should have the client applications for web, mobile, and desktop.

If users upload a new screenshot, it will be available in 100 milliseconds.

The users can upload a screenshot maximum 1 MB.

Users may choose the users with whom they share the screenshots or make a screenshot public.

The platform should be designed to handle a high number of concurrent users efficiently. This might involve implementing techniques like load balancing and caching to distribute requests and minimize response times.

The system architecture should allow for horizontal scaling to accommodate increasing user traffic and data volume. This could involve using distributed databases and cloud-based infrastructure.

User data, including passwords and personal information, should be securely stored using encryption techniques.

The user interface (UI) should be intuitive and user-friendly for both novice and experienced users. A clean and well-organized UI with clear navigation elements will enhance user experience

Capacity estimation

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

Here's the calculation for storage requirements based on the provided assumptions:

• Users per month: 1,000,000
• Screenshots per month: 1000
• Screenshot size per user (assumed): 1 MB
• Data storage: 1,000,000 users * 1,000 * 1,000,000 = 1 Petabytes
• 365 * 1000000000000000. = 770 Petabytes per year

Therefore, based on the assumptions, the estimated storage requirement for the system would be around 770 Petabytes per year.

API design

Define what APIs are expected from the system...

Here's a breakdown of the essential API for our Multi-Device Screenshot Capture System.

User Management APIs:

• User registration: allows users to create new accounts and potentially other profile information.
• User login: enables users to authenticate with their credentials and obtain a secure access token for subsequent API calls.
• User Profile Management: provides functionalities for users to update their profile, information, contact details, and potentially manage preferences.

Screenshot Management APIs:

• Get a list of screenshots for a current user: returns information about the screenshots, including id, title, user_id, creation date, tag list, size, URL to download, public or private status, and if private, the user_id list and who can download the screenshot. It includes paging information, such as the page number and its size.
• Get the information about a screenshot for the given screenshot_id, including id, title, user_id, creation date, tag list, size, URL to download, public or private status, and if private, the user_id list and who can download the screenshot
• Remove the screenshot for the given screenshot_id
• Download the screenshot for the given screenshot_id and size.
• Upload the new screenshot: using HTTP stream, the current users can upload the screenshot with such information: id, title, user_id, creation date, tag list, size, public or private status, and if private, the user_id list and who can download the screenshot.
• Search the downloaded screenshot by keywords.

Database design

Database Choices:

User :

Database type: SQL (MySQL, PostgreSQL)

Reasoning: user data requires strong consistency and ACID transactions.

Screenshot:

Database type: NoSQL (DynamoDB)

Reasoning: It may work with eventual consistency.

HashTag and Permission:

Database type: SQL (MySQL)

Reasoning: they require strong consistency and ACID transactions.

Data partitioning strategy:

Reasoning: User Id is a natural partitioning key as users primarily interact with user their data and advertisements. Sharding by User Id distributes load across servers and facilitates horizontal scaling for the user and screenshot data.

Sharding strategy: User Id provides a well-defined partition key for efficient data distribution and horizontal scaling based on user base growth. This approach keeps user data and related screenshots together on the same shards.

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

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

Failure scenarios/bottlenecks

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

Future improvements

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