Design Digital Asset Management

The box diagram looks easy: an upload box, a storage box, a download box. The difficulty hides in the size of the things moving through it. A single original can be a 50-megabyte RAW photo, a multi-gigabyte 4K video, or a layered file the size of a small download on its own. None of those is usable as-is. The work is turning a huge, slow, unusable original into many small, fast, ready forms without making the user wait on any of it.

File size is what changes the architecture. Pushing a few gigabytes through an application server means that server holds the whole transfer in flight, and a thousand concurrent uploads would melt it. So the bytes skip the app tier and land straight in blob storage. Then the original is useless until it is processed. A browser cannot show a RAW file or a layered design file. Before the asset is really "there," the system has to generate a viewable preview, a stack of thumbnail sizes, transcoded video formats, plus extracted metadata and machine tags. That work takes seconds to minutes per file, far too long to hold an upload request open. Big bytes and slow processing are the two facts that split this into separate paths, each with its own design.

Fix the read-versus-write shape before drawing anything, because it sets where the money goes. An asset is uploaded once and processed once, then viewed and downloaded over and over, often by many people, for years. The write path is heavy but rare per asset. The read path is light per request but enormous in aggregate, and it has to feel instant from anywhere on earth. That asymmetry is why a content delivery network sits in front of storage. Generating the right small forms up front pays for itself across millions of later reads. Call out the ratio early. It justifies half the design.

The Adobe angle

This is Creative Cloud, and a generic file-uploader answer gives you away. Lightroom holds people's entire photo libraries. Creative Cloud syncs multi-gigabyte design files across desktops.