---
title: 'Avoid This Common System Design Mistake: Use Pre-signed URLs for Uploads'
source: 'https://youtube.com/watch?v=dW-meGlxS0c'
video_id: 'dW-meGlxS0c'
date: 2026-08-04
duration_sec: 69
---

# Avoid This Common System Design Mistake: Use Pre-signed URLs for Uploads

> Source: [Avoid This Common System Design Mistake: Use Pre-signed URLs for Uploads](https://youtube.com/watch?v=dW-meGlxS0c)

## Summary

This video explains a common mistake in system design interviews: uploading large files through an API server to S3, which wastes resources. It presents the solution of using pre-signed URLs to allow direct client-to-S3 uploads, improving efficiency and scalability.

### Key Points

- **Common Upload Mistake** [00:00] — Candidates often design a system where the client uploads a file to the API server, which then forwards it to S3. This results in paying for the transfer twice and tying up server resources.
- **Problem with Server-Relayed Uploads** [00:13] — A 2GB video upload holds a server thread hostage for the entire transfer. With 10,000 concurrent uploads, servers become overwhelmed with moving bytes instead of doing application work.
- **Solution: Pre-signed URLs** [00:25] — The client requests an upload slot from the API. The server generates a time-limited, pre-authorized URL pointing directly to S3 and returns it to the client.
- **Direct Upload and Event Handling** [00:37] — The client uploads directly to S3, bypassing the server. Once S3 finishes, it can trigger a completion event to start downstream tasks like transcoding or metadata updates.
- **Benefits and Resource Efficiency** [01:03] — The API now handles only a few hundred bytes of JSON instead of gigabytes of binary data, which is the appropriate workload for an application server.

### Conclusion

Using pre-signed URLs for direct client-to-S3 uploads is a scalable and efficient pattern that avoids wasting server resources, making it a key concept for system design interviews.

## Transcript

The client uploads a video to your server. Your server then uploads it to S3. But be careful, you just paid twice for the exact same work. This is one of the most common mistakes I see in system design interviews. A candidate's building a system where they need to upload a big file,
and their first instinct is to send that file to the API server and then have the server forward it to S3. On the surface, this works, but then it doesn't. A 2GB video upload holds a server thread hostage for the entire transfer.
At 10,000 concurrent uploads, your servers aren't doing application work anymore. They're just moving bytes around and wasting memory. The fix is what's called a pre-signed URL. Your client just asks the API for an upload slot.
Your server generates a time-limited, pre-authorized URL, pointing directly at S3 and hands it back. Now the client uploads straight to S3, and your server never touches that file. When S3 finishes, it can fire off a completion event,
and then kick off all that downstream transcoding or updating a metadata or anything else you need to do. Your API went from handling gigabytes of binary data to handling just a few hundred bytes of JSON, which is the right job for an application server.
Learn more to prepare for your interviews at hellointerview.com.