Module 09 · Storage systems · Lesson 3 of 4
Object storage
Buckets of immutable objects behind an HTTP API, with eleven nines of durability and near-infinite capacity. Presigned URLs for direct upload, key layout and multipart, consistency and versioning, storage classes and lifecycle.
Why it matters
User uploads, images, videos, backups, logs, data lake files and static sites all end up in object storage, because it is the only storage tier that is effectively unlimited, extremely durable and cheap per gigabyte at the same time. Nearly every system design has a bucket in it somewhere. The interview questions are about how to use it well: how uploads bypass your servers, how keys are laid out, how costs are controlled over time, and what consistency you get.
The idea
Object storage stores objects (bytes plus metadata) under keys in buckets, accessed over HTTP: put, get, delete, list by prefix. Objects are immutable; to change one you write a new version. There is no hierarchy, only keys that may contain slashes, and no random writes. In exchange you get durability designed around 99.999999999 percent per year (eleven nines), capacity that scales without planning, and a price around a cent or two per gigabyte-month.
How it achieves durability
Each object is split into fragments with erasure coding (next lesson) and spread across many disks, racks and availability zones, so several simultaneous failures lose nothing. Background processes continuously verify checksums and repair fragments. Metadata is kept in a separate, replicated index. Because the system assumes constant hardware failure and repairs faster than failures accumulate, the durability figure is a design target rather than a hope. Availability is lower than durability (typically 99.9 to 99.99 percent), which is why applications retry and why critical paths cache.
Direct upload and download with presigned URLs
Routing a 2 GB video through your API servers wastes their bandwidth and memory. Instead the API issues a presigned URL: a time-limited, signed link that grants the client permission to put or get exactly one key, and the client talks to the object store directly. The server records the upload's existence (and validates it afterwards or via an event notification) without ever touching the bytes. Downloads work the same way, or through a CDN in front of the bucket for public assets.
Keys, listing and hot spots
Keys are flat, but prefixes act as folders for listing and for permissions. Lay keys out for the queries you will run: tenant/42/invoices/2026/11/… lets you list a tenant's invoices for a month and apply a lifecycle rule per prefix. Listing is paginated and relatively slow; do not use the bucket as a database, keep an index of objects in your database instead. Modern object stores partition by key prefix automatically and sustain thousands of requests per second per prefix, but an extremely hot single prefix can still throttle; spread very high request rates across prefixes.
Multipart, large objects and consistency
Objects up to several terabytes are uploaded in parallel multipart pieces (5 MB to 5 GB each) that the store assembles, with the ability to resume failed parts. Major object stores are now strongly consistent for reads after writes and for listings, so a client that writes then reads sees the new object; older designs were eventually consistent for overwrites and deletes, which is why you still see advice about unique keys. Versioning keeps every version of a key, protecting against accidental overwrite and deletion; object lock makes versions immutable for compliance.
Storage classes and lifecycle
| Class | Cost per GB | Retrieval | Fits |
|---|---|---|---|
| Standard | Highest | Immediate, free | Active data: uploads, assets, recent logs |
| Infrequent access | Lower | Immediate, charged per GB | Data read a few times a year: older logs, backups |
| Archive (Glacier-style) | Lowest | Minutes to hours, charged | Compliance retention, cold backups |
| Intelligent tiering | Automatic | Immediate | Unknown or changing access patterns |
Lifecycle policies transition objects between classes by age and delete or expire them, so storage cost falls as data cools without any application code. Costs are not only storage: request charges, egress to the internet (often the largest line) and retrieval fees for cold classes all matter, which is why a CDN in front of public assets saves money as well as latency.