System requirements

Functional:

1. User Authentication:
   • Users should be able to register, log in, and manage their accounts.
2. Video Uploading:
   • Users should be able to upload videos in various formats and specify metadata (title, description, tags).
3. Video Playback:
   • Users should be able to watch videos seamlessly in different resolutions.
4. Search Functionality:
   • Users should be able to search for videos based on titles, tags, or descriptions.
5. User Interactions:
   • Users should be able to like, comment, and share videos.
6. Subscription System:
   • Users can subscribe to channels and receive notifications for new uploads.
7. Video Recommendations:
   • The system should recommend videos based on user preferences and viewing history.
8. Content Moderation:
   • The platform should include a mechanism for reporting inappropriate content.
9. Analytics:
   • Users should have access to analytics on their video views, likes, and comments.
10. Video Categorization:
    • Videos should be categorized into different genres or categories for easy discovery.

Non-Functional:

1. Scalability:
   • The platform should handle a large number of concurrent users uploading and watching videos without performance degradation.
2. Performance:
   • Video streaming should have low latency and quick loading times, allowing users to start watching videos almost instantly.
3. Reliability:
   • The system should be highly available, with minimal downtime, providing a consistent user experience.
4. Security:
   • User data and videos should be protected from unauthorized access. Secure authentication methods should be in place.
5. Usability:
   • The platform should be user-friendly and intuitive, making it easy for users to navigate, upload, and find content.
6. Maintainability:
   • The system should be structured in a way that makes it easy to update and maintain over time, including fixing bugs and adding new features.
7. Compatibility:
   • The platform should work seamlessly across various devices (desktop, mobile, tablet) and browsers.
8. Data Integrity:
   • The data stored (user information, videos, comments, etc.) must remain accurate and consistent, ensuring users can trust the system.
9. Latency:
   • The system should ensure that the time taken to upload, process, and serve videos is minimized.
10. Compliance:
    • The platform should adhere to legal regulations (like copyright laws) and data protections (like GDPR).

Capacity estimation

• Storage Requirement: 1 TB per day
• User Traffic: 500,000 video views daily
• Active Users: 100,000 daily

Per year: 1 TB * 365 = 365 TB

RPS = 500000 / 24 * 60 * 60

API design

Functions:

/netflix/user POST (create_user)

/netflix/user?user_id GET (get_user_data)

/netflix/video?video_hash GET (watch_video)

/netflix/video POST (upload a video)

/netflix/video/lookup POST (lookup videso by tags, metadata etc.)

/netflix/video/like?video_hash POST (like a video)

/netflix/video/comment?video_hash POST (post a comment on a video video)

/netflix/videos/recomendation?user_id GET (get recomended videos)

Database design

User : +int RecordID

User : +int UserID

User : +String UserName

User : +String HashedPassword

User : +String Email

User : +DateTime CreatedAt

Video : +int RecordID

Video : +int VideoID

Video : +String Link

Video : +int LikeID

Video : +DateTime CreatedAt

Like : +int RecordID

Like : +int LikeCount

Like : +int DisLikeCount

Like : +int LikeID

Comments : +int RecordID

Comments : +int VideoID

Comments : +int UserID

Comments : +String Comment

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

For video encoding:

1. Encoding Queue:
   • A message queue (like RabbitMQ or AWS SQS) that handles incoming video upload requests. Each request will be processed to distribute the workload across multiple encoders.
2. Video Encoders:
   • Multiple encoding servers that process videos in parallel, converting them into various formats and resolutions (adaptive streaming).
3. Short Term Video Storage:
   • A temporary storage solution (like an S3 bucket with a special access configuration) designed for hot videos, allowing quick retrieval for streaming shortly after upload.
4. Long Term Storage/CDN:
   • Videos that have been processed will be migrated to a Content Delivery Network (CDN) for long-term storage and access. This reduces latency for users accessing older videos and offloads traffic from your main servers.

For recomendations service:

1. Dedicated ML Service:
   • Handles the machine learning algorithms that analyze user data, video preferences, and viewing patterns to generate recommendations.
2. Distributed Computing:
   • A system that uses multiple machines to perform computations efficiently. Frameworks like Apache Spark or distributed computing resources from cloud providers can be used to process large data sets in parallel.
3. Recommendation Storage (Regular DB):
   • A traditional database that stores the generated recommendations (either as precomputed lists or user-specific recommendations) for quick access during user requests.

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

Video Encoding with a Queue Service:

1. Dynamic Encoder Selection:
   • By placing upload requests into a queue, you have the flexibility to scale dynamically. If an encoder fails or becomes overwhelmed, you can easily add new encoder instances to process requests without service disruptions.
   • This system architecture allows for a decoupled approach where each encoder operates independently, thus improving overall throughput.
2. Failure Handling:
   • Implementing retries for failed encoding jobs can ensure that if an encoder fails during processing, the job can be automatically reassigned to another available encoder without requiring user intervention.

CDN Migration as a Background Process:

1. Asynchronous Migration:
   • Handling CDN migrations in the background allows for the main user-facing operations to continue without interruption. Videos can be migrated at a controlled pace during off-peak times to reduce the load on your primary storage.
   • Implementing regular checks on the status of the migration can help ensure all videos are successfully moved, and any failures can be logged for analysis.
2. Retry Logic:
   • For failed migrations, the system should automatically initiate retry logic. If a migration operation doesn’t complete successfully, you can have a scheduled task or a retry mechanism to ensure the content eventually reaches the CDN.
   • This not only provides a safety net but can be complemented with alerts to inform your operations team of persistent failures.

Strategy for Authentication Service Downtime

1. Return Service Overloaded Error Code:
   • When the authentication service is unavailable or experiencing high load, returning a standardized error code such as HTTP 503 (Service Unavailable) informs users that the service is temporarily unavailable.
   • You can pair this with a clear user message to indicate that the service is overloaded, reassuring users that their attempts were acknowledged and that the issue is being addressed.
2. Read Replicas:
   • Implementing read replicas for the user database allows you to scale read operations, effectively distributing the load.
   • This setup helps alleviate pressure on the primary database, especially during peak usage when many users attempt to log in or access their profiles simultaneously.
   • If the primary database experiences high load or a failure, you can redirect read requests to the replicas, ensuring users still get access to critical data (though write operations would still be directed to the primary).

• Throttling: Implement request throttling to limit the number of login attempts from a single user or IP, helping to manage high loads and prevent abuse.

Future improvements

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