System requirements

Functional:

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:

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

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. = 370 Petabytes per year

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

API design

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

Here's a breakdown of essential components and services required to build your Multi-Device Screenshot Capture System.

Client application: Many types of client applications for web, mobile, and desktop.

Responsibilities:

• User registration and login
• Make and upload the screenshots with assigned keywords or hashtags
• Download the other screenshots to view with websockets.
• User profile management
• Retrable upload the new screenshots with the websocket connections in the specific formats.

API Gateway: API Gateway software - Apigee, Istio, AWS API Gateway.

Responsibilities:

• Serves as a single entry point for all API requests from the client applications
• Routes requests to the appropriate backend services based on their functionalities.
• Implements authentication and authorization mechanisms to secure access to APIs.

User Service: Manage user activity, including user creation, removal, and searching.

Responsibilities:

• Manages user profile information.
• Interacts with the user database to store and retrieve user data.
• Send an update event to Kafka

Upload service: manage to either upload or download the screenshots by user demands.

Responsibilities:

• Accepts the user's websocket connection to download or upload a screenshot
• Persist the uploaded screenshot to the object storage
• Persist the screenshit information to DynamoDB
• Send the event about the new screenshot to Kafka

Search service: look for the screenshot information by keywords.

Responsibilities:

• Store the keywords and screenshot_id to MySQL
• Search the screenshot_id by a keyword
• Receive the event from Kafka to persist new screenshot_id and keywords (hashtags).

Permission service: manage the user's permission to work with a screenshot.

Responsibilities:

• Find the screenshot_id and read and write boolean flags for the given user_id
• Persists the screenshot_id,user_id, and read, write boolean flags to MySQL
• Receives the event from Kafka to persist the new user and their permissions.

Notification Service: listen to Kafka about new screenshots and connected users, and store that information to Redis.

Responsibilities:

• Receive the user login events and store connection information in Redis
• Connect to the client application to notify about new screenshots to make all user application will be updated.

CDN: store the screenshots closest to clients.

Security layer: Secure communication protocols (HTTPS), authentication, and authorization mechanisms, intrusion detection/prevention systems.

Responsibilities:

• Protects user data and platform integrity from unauthorized access and security threats
• Ensures secure communication channels and data encryption.

Request flows

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?