11. Object / Blob Storage
1
The picture to keep in your head2
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 breaks12
Practice: five levels13
Interview questions14
Solutions15
Sources16
Code lab11. Object / Blob Storage
11.3 What are buckets, keys and metadata?
3 min read+10 XP
At the cloakroom: The hall has separate cloakrooms (one for the bride's side, one for the groom's), each with its own rules. Inside, each coat has a token number and a tag.
In the system:
- A bucket is a top-level container with its own name, region, access rules and settings. Teams often use separate buckets for public and private content: the bookstore keeps covers in a public bucket and paid PDFs in a private one.
- A key is the object's full name inside the bucket, like
ebooks/42.pdf. Keys look like paths, so you can list by prefix ("everything starting withcovers/42/"), but there are no real directories. - Metadata is information stored with the object: system metadata like content type (
image/jpeg), size, last modified, an ETag (a fingerprint of the content), plus your own key-value tags (book-id: 42).
Key design tips:
- Make keys predictable from your data (
covers/{book_id}/{size}.jpg), so you can build URLs without a lookup. - Never put secrets or personal data in keys; they show up in URLs and logs.
- To change a file, write a new object (or a new version). Many teams put a version or hash in the key (
covers/42/large-v3.jpg) so caches never serve an old copy (Chapter 26).
Memory code: "Bucket is the cloakroom, key is the token, metadata is the tag."