A design platform stores billions of user assets and rendered outputs, where a small fraction are accessed constantly and most are never accessed again after the first week. Design the storage architecture.

The access distribution decides everything

The shape is consistent across media platforms: a steep decay curve. An asset is accessed heavily on creation day, occasionally in the following week, and essentially never after a month — with a small tail of evergreen content that stays hot for years.

One storage class for that distribution is either expensive (everything on hot storage) or unusable (everything on cold storage, so the recently created assets a user is actively editing take seconds to retrieve).

The architecture

Object storage as the substrate, not a database. Assets are immutable blobs with content-addressed keys. Content addressing gives deduplication for free, which matters enormously on a platform where users copy templates — the same stock photograph exists in an enormous number of designs and should be stored once.

Lifecycle policies moving objects between tiers by age and access. Standard for the first weeks, infrequent-access thereafter, archival beyond that. The saving is substantial and the mechanism is declarative rather than code.

Intelligent tiering for the unpredictable tail, where the platform pays a small monitoring fee to let the provider move objects based on observed access rather than on a policy that cannot know which asset becomes evergreen.

A CDN in front of everything user-facing, so the storage tier's latency is invisible for anything recently or repeatedly accessed. This is what makes aggressive tiering safe: the cold tier is only reached on a genuine cold miss.

Metadata in a database, content in object storage. The database holds ownership, permissions, versions, and the storage key. It never holds the bytes.

Derived artefacts treated as a cache, not as data. Thumbnails, previews and rendered exports are regenerable. Store them in a cheaper tier with a shorter lifecycle, and be willing to delete and regenerate rather than paying to retain them forever.

The details that catch teams out

• Retrieval cost and latency on cold tiers. Archival storage is cheap to hold and expensive to read, sometimes with retrieval times measured in hours. An asset a user might reopen must not be in a tier that takes hours, whatever the policy says.
• Minimum storage durations. Cold tiers bill a minimum retention; moving an object down and back up quickly costs more than leaving it. Lifecycle policies that thrash are a real and common cost bug.
• Request costs at scale. Billions of small objects means request charges can exceed storage charges. Batching small assets into larger objects is sometimes the right answer.
• Deletion and deduplication interact. With content addressing, deleting a user's asset must not delete a block another user references — reference counting is required.
• Egress. Serving directly from object storage to users is expensive; the CDN is a cost control as much as a latency control.

The principle

In media-heavy systems, storage class is a function of access probability, and access probability is predictable from age plus a small number of signals. Building the tiering as declarative lifecycle policy rather than application logic is what keeps it correct as the platform grows.