Design a Media Asset Management System

Problem statement

Design a centralized media asset management (MAM) platform where production teams upload raw footage, images, audio, and documents; the system organizes them with rich metadata and AI-generated tags, generates proxies and previews through a transcoding pipeline, exposes faceted search, and enforces role-based and license-based access for thousands of collaborators and downstream editing tools.

This is not a consumer photo app and not a generic object store front-end. A single camera magazine from an ARRI or RED shoot can exceed 2 TB. A season of episodic television can produce several petabytes of mezzanine material. Editors need a 2 MB proxy in under two seconds while the 4.5 GB master is still being checksummed. Rights teams need an embargo to be mathematically impossible to violate at 3 a.m. on premiere day. Marketing needs a three-year-old clip found by scene content, not just by filename.

Why the problem is distinctive

A generic file service can retry a failed copy. A media supply chain cannot retry a corrupted master, re-shoot a live sports event, or explain to legal why an embargoed trailer leaked through a preview URL. The design therefore separates four concerns that must never be merged:

1. Byte integrity: the uploaded object is bit-for-bit what the camera produced, verified end to end with checksums and manifest digests.
2. Derivative generation: proxies, thumbnails, HLS ladders, and audio waveforms are disposable, regenerable children of an immutable master version.
3. Catalog truth: the asset record, its version lineage, metadata, tags, and rights are the only strongly consistent state in the system.
4. Governed access: every byte leaves the system through a signed, scoped, expiring, watermarked, auditable grant.

Public operating baseline versus design assumptions

Public evidence establishes that the category operates at extreme scale. YouTube has publicly reported more than 500 hours of video uploaded per minute, and AWS has publicly described Amazon S3 as storing hundreds of trillions of objects. Adobe announced the acquisition of Frame.io, a cloud video collaboration platform, for $1.285 billion, and Frame.io publicly markets camera-to-cloud workflows with frame-accurate review. Netflix engineering talks describe media supply chains where a single title expands into hundreds of thousands of encoded files across codecs, resolutions, languages, and regions. These are cited public signals, not requirements for our system.

For capacity planning this answer explicitly assumes a mature studio network: 250 million cataloged assets, 120 petabytes of masters, 40,000 assets and 180 terabytes ingested per day, 8,000 production seats with 2,500 concurrent at peak, 90,000 transcode jobs per day, and a 5x event peak around premieres and press days. Unless a number is tied to a citation, it is a stated design assumption, target, or budget.

The four architectural planes

1. Ingest plane: resumable chunked upload, integrity verification, virus scanning, deduplication, quarantine, and manifest construction.
2. Processing plane: transcoding orchestration, derivative fan-out, AI analysis, quality control, and cost-aware worker pools.
3. Catalog plane: asset and version records, metadata, tags, rights, search index, and lineage.
4. Delivery plane: signed download, HLS proxy streaming, API access for NLE plugins, webhooks, and watermarking.

A strong interview answer keeps these planes separate. A transcode outage degrades previews but never corrupts masters. A search index failure degrades discovery but never weakens rights enforcement. A delivery spike never touches the ingest path.