Art of Codeartofcode
Lesson 9 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.8 How should files be served to users?

3 min read+10 XP

At the cloakroom: If guests from every city come to one cloakroom to collect souvenirs, the queue stretches out the door. Better: send copies of the popular souvenirs to small counters near each city.

In the system: You can serve objects straight from the bucket, but for anything popular, put a CDN (Chapter 26) in front:

  • The CDN keeps copies at edge locations near users, so covers load fast in Mumbai and in Berlin.
  • Your bucket serves each object once per edge instead of once per user, which cuts egress (data-out) costs, often the biggest line on a storage bill.

For the bookstore, assume 50 million cover views a day at about 100 KB each: about 5 TB a day leaving storage, about 0.46 Gbps on average, more at peak. A CDN absorbs nearly all of it.

Two practical rules:

  • Public, popular, rarely changing (covers): CDN with long cache times and versioned keys, so updating a cover is a new key, never a stale cache.
  • Private (paid PDFs): presigned URLs with short expiry, or a CDN that supports signed URLs or cookies, so only buyers can download.

Memory code: "Popular coats go to counters near the guests."