Art of Codeartofcode
Lesson 5 of 16

11. Object / Blob Storage

1
The picture to keep in your head
2
11.1 What's the difference between block, file and object storage?
3
11.2 Why not just store files in the database?
4
11.3 What are buckets, keys and metadata?
5
11.4 How do uploads work with presigned URLs?
6
11.5 How do you upload very large files reliably?
7
11.6 How does object storage avoid losing files?
8
11.7 What are storage classes and lifecycle rules?
9
11.8 How should files be served to users?
10
11.9 What happens after a file is uploaded?
11
Memory card and where the analogy breaks
12
Practice: five levels
13
Interview questions
14
Solutions
15
Sources
16
Code lab
11. Object / Blob Storage

11.4 How do uploads work with presigned URLs?

3 min read+10 XP

At the cloakroom: Instead of the host carrying every guest's coat to the cloakroom personally, the host writes a signed note: "allow this guest to leave one coat at hook 214, valid for the next ten minutes". The guest takes the coat there directly.

In the system: The naive design streams every upload through your API servers: the phone sends 8 MB to your server, which sends it on to storage. Your servers spend their time and bandwidth shuttling bytes.

A presigned URL lets the client talk to storage directly, with permission your backend grants:

uploading a review photo with a presigned URL: ask, get signed URL, upload directly, confirm, save key.

Figure: your API handles a tiny request; the heavy bytes go straight to storage.

  1. The app asks your API: "I want to upload a review photo."
  2. Your API checks the user is allowed, picks the key (reviews/7/981.jpg), and creates a presigned URL: a normal storage URL plus a signature made with your secret credentials, covering the method (PUT), the key, and an expiry time (say 10 minutes).
  3. The app uploads the bytes directly to storage with that URL.
  4. Storage tells your system the upload is done (an event notification), or the app tells your API.
  5. Your API saves the key and metadata in the database.

Downloads work the same way: the private e-book PDF is served by a short-lived presigned GET URL made only after checking the user bought it.

Security rules: the signature must cover everything that matters (method, key, expiry, and limits like content type or size where supported), so the URL can't be reused for another file, another action or a longer time (the Level 4 bug). Keep expiry short. On S3, presigned URLs signed with long-term credentials can last at most 7 days.

Memory code: "A signed note for one coat, one hook, ten minutes."