Requirements

In one line: two requirements here are unusual for a storage system — strong consistency, which most object stores historically did not offer, and a retention period before permanent deletion, which is why Lesson 11 needs a garbage collector.

The hierarchy

Users create containers to group blobs — for example, separating user data or media types. A single user can own multiple containers, each holding many blobs.

We assume containers cannot be nested.

'Containers cannot be nested' is the flat namespace, restated as a constraint

This is Lesson 1's flat organization made concrete, and it is worth noticing that it is an assumption the design chooses, not a physical limitation.

Nesting would reintroduce a tree, and with it the directory objects, traversal, and locking that the flat model exists to avoid. Two levels — account and container — are enough to give users organization, and both are fixed depth, so lookups never walk an arbitrary chain.

Users who want deeper structure get it through naming: 2024/summer/img1.jpg inside one container. The illusion of hierarchy, with none of the cost. That is exactly how S3 and GCS behave, and it is why Lesson 9's listing works on a prefix.

Functional requirements

'Retention periods before permanent deletion' is the requirement that shapes deletion

Delete does not mean "the bytes are gone." It means the blob becomes inaccessible, with actual reclamation happening later.

Two independent reasons force this, and it is worth having both:

Performance. Lesson 11 explains it: a blob's chunks are spread across many data nodes with replicas on each, so synchronously deleting every copy would make delete a slow, fan-out operation. Marking one metadata row is fast.

Safety. A retention period is an undo window. Accidental deletion is one of the most common data-loss causes in practice, and giving users a recovery window is more valuable than reclaiming disk instantly.

The consequence to carry forward: deleted-but-not-yet-reclaimed storage is a real, ongoing cost, and you need a garbage collector to eventually bound it. Lesson 11 covers both.

'Access a blob via a system-generated URL' is doing more than it looks

The system generates the URL rather than the user choosing it. That means the URL can carry more than a location — it can encode identity, access level, and expiry.

That is the mechanism behind pre-signed URLs: a time-limited, capability-bearing link that grants access to one blob without the recipient having an account. It is how a browser downloads a private file directly from storage without the application proxying the bytes, which matters enormously for the bandwidth numbers in the next lesson.

Lesson 7's write workflow returns exactly this — the fully qualified path including user ID, container ID, blob ID, and access level.

Non-functional requirements

Durability is the strongest guarantee in this course so far

"Data must persist until explicitly deleted" is an unbounded commitment, and it is worth comparing across the building blocks you have built:

• A cache may lose everything and still be correct — the design of truth is elsewhere.
• A messaging queue must not lose an acknowledged message, but only until it is consumed and retention expires.
• A blob store must hold the data forever, or until the user says otherwise. There is no source of truth behind it — it is the design of truth.

That is why Lesson 10's replication is three geographically separated copies rather than three machines in a rack, and why cloud providers quote durability in nines like 99.999999999%. The whole design exists to make "we lost your video" impossible.

Strong consistency is a notable choice — object stores historically didn't offer it

"All users see the same view of a blob" sounds obvious and was, for years, not how object stores worked. S3 offered eventual consistency for overwrites and deletes until 2020; a read after a write could return the old object or a 404.

Two things make strong consistency achievable here. Immutability (Lesson 1): with no in-place updates, the only race is create-then-read, which is far easier than reconciling concurrent overwrites. And synchronous replication within the cluster (Lesson 12), which is affordable because those replicas are nearby.

Note what stays eventual: cross-region replication is asynchronous, so a remote region can lag. That is the same PACELC trade distributed caching made — strong consistency locally, eventual across regions, because the latency is not payable.

Building blocks used

Interview signal by level

Next: sizing it.