A System Design interview with an Amazon engineer

Watch someone solve the video upload API problem in an interview with an Amazon engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type
Video upload API
Interview question
Design a backend service for uploading videos on a large scale.

Interview Feedback

Feedback about Wicked Gyroscope (the interviewee)

• Advance this person to the next round? Yes
• How were their technical skills? 4/4
• How was their problem-solving ability? 3/4
• What about their communication ability? 4/4

Good job tackling the design problem today. You did a good job coming up with a high-level design and has all the right components for this service. Because of that, I rate this interview as a pass.

We discussed the feedback in the last 20 min, and below is a brief summary:

• whenever you use a dependent, make sure to find out as much as possible about its SLA
• consider using a coordinator to manage the fleet of workers, that allows you to keep track of its health and scale
• focus on discussing how to scale your system and how to make your system fault-tolerant

Interview Transcript

Hot Gyro: Hello.
Wicked Gyroscope: Oh, hi.
Hot Gyro: Can you hear me?
Wicked Gyroscope: Yeah, I can hear you.
Hot Gyro: I can hear you. Okay. So looks like we have a system design session.
Wicked Gyroscope: Yeah.
Hot Gyro: So I think the way it works is that I have a question, and we'll spend about 40 minutes for you to design, and then I'll give you some feedback. And after that, we'll do a quick Q&A. How does that sound?
Wicked Gyroscope: Okay, great.

Hot Gyro: So, here, here we go. Imagine you are designing a video processing system. Okay. So let me explain a little bit here. We're talking about a backend service, right? And this service is a video conferencing system, which will handle a lot of the video uploads by the client. The way the system processes the videos is by calling a third party, or sorry, calling an internal service that another team has to actually do the processing, right? So you're not building the actual processing unit; you're calling another service to actually process each video, but you need to design a workflow to handle a lot of videos that are coming into the service.

Wicked Gyroscope: Okay. And what my system should do is internal service already done these functions?

Hot Gyro: Yeah, so there is an internal service available for you to use. But that internal service only processes one video, right? You need to build an overall video processing system to handle a lot of videos that are uploading to your service.

Wicked Gyroscope: Okay, so... Okay, can you explain what processing means? You talked about, okay, I sent a video as is to this API, yes, and to this internal service, and on the output I have some metadata? Yeah. And it does store this metadata in another component for using in other components?

Hot Gyro: Yeah, maybe I can explain this again, slightly differently. Assume you have like n videos coming in, right, into your video processing system. For each video, you will call this internal service, which is a kind of machine learning type of processing, this internal service that you need, you don't have to worry about what they do. You need to make sure that every video that comes in calls that internal service.

Wicked Gyroscope: Okay, so now I understand more. Okay, and after that, I don't care about it, so I need to get on the bus how I store, how I take video in from user. Yes? And I don't care about the processing. Okay.

Hot Gyro: Yeah. So, I think you asked a good question here about storage. Every video uploaded to your server will need to be stored somewhere for at least five years.

Wicked Gyroscope: So I wrote down some features. Not to forget. So yeah, we need to store, the user can upload videos. Yes. And you have this stored for five years. Okay. So I need to send them for internal processing. Okay, so I have questions.

Hot Gyro: Yeah, that's a good question about the requirements here. How much time between the upload to the actual processing, right? Yeah, there is no requirement here, so you are free to design, whatever it is. Because... Think of the user as just uploading video to your server. They don't need to retrieve the data if they upload it.

Wicked Gyroscope: Okay, we can assume some latency but we want to do this as fast as possible. It would be optimal.

Hot Gyro: So as soon as possible, right? That’s the requirement.

Overall System Description

1. User Uploads Video: Users can upload multiple videos.
2. Storage: Videos are stored for at least five years.
3. Video Processing: Each video is sent to an internal service for processing.
4. Database Interaction: Metadata about videos is stored in a MongoDB database.
5. Queue System for Processing: Use a queue to manage processing.
6. Workers: Workers read tasks from the queue to manage the video processing once it is uploaded.
7. Error Handling: System should have retry mechanisms when uploading videos.
8. Monitoring and Health Checks: Systems should monitor worker health.

Potential Challenges

• Dependency Management: All dependent services must have stable SLAs to ensure reliability.
• Concurrency and Scalability: The system should handle multiple concurrent uploads and be able to scale horizontally.
• Data Consistency: Ensuring that metadata and video files remain in sync during processing.

This proposal covers the main functionality and requirements as discussed in the interview. The system outlined needs to ensure fault tolerance, scalability, and to manage resources effectively over assigned timelines.