Problem Statement: A Cloud-Native Non-Linear Editor
Frames the product as a compiler-style editing platform: the browser owns interaction, the cloud owns media, preview, and rendering.
Problem statement
Design a web-based video editor. Users upload or import footage, arrange clips on a multi-track timeline, trim and split, add transitions, text overlays, music, and effects, preview the result in near real time, and submit a cloud render that produces a final cut they can download or share. The brief also asks us to consider multi-user concurrency and project sharing, so collaboration is a first-class design input rather than an afterthought.
The trap is to picture a desktop NLE and move it to a browser. That fails immediately on physics: a user's source media may be 4K H.264 or HEVC at tens of gigabytes, while a browser tab cannot decode, composite, and scrub several such streams in real time from object storage. The design therefore splits into two planes with opposite personalities. The interactive plane needs low latency and tolerates approximation: proxies, preview effects, presence. The render plane needs throughput and exactness: batch workers, frame-accurate effects, durable outputs.
The central abstraction is that the timeline is a document, not pixels. Every edit is a declarative operation on a versioned composition graph - clips referencing immutable source assets, effect parameters, keyframes, transitions. Rendering is a compile step from that document to an output file. This is exactly how Descript describes its 'sequence' model and how Kapwing's engineering blog describes compiling a scene graph into FFmpeg filtergraphs. Once you say 'timeline is data, render is compilation', the rest of the architecture falls out: document sync for collaboration, immutable content-addressed media, a preview pipeline that approximates the compile, and a render farm that executes it.
The four architectural planes
- Media ingest and storage: chunked resumable uploads, probing, scanning, content-addressed originals, derived proxies.
- Editing document and collaboration: versioned timeline documents, operations, presence, comments, roles.
- Preview pipeline: proxy transcodes, thumbnails, sprite sheets, client-side WebCodecs/WebGL compositing.
- Render farm and delivery: job planning, segmented rendering, assembly, QC, output storage, CDN delivery.
Public operating baseline
The category is real and large. YouTube has publicly reported roughly 500 hours of video uploaded per minute, Canva publicly reported more than 190 million monthly active users in 2023 with video a core surface, CapCut is consistently ranked as the top mobile editing app with estimates above 200 million monthly users, and Adobe acquired Frame.io for $1.275 billion in 2021 principally for its camera-to-cloud and review infrastructure. These are cited public figures for context, not requirements for our fictional system.
For capacity planning this answer explicitly assumes a mature product with 8 million MAU, 900 thousand DAU, 60 thousand concurrent editor sessions at peak, 150 thousand new uploads per day averaging 800 MB, and 60 thousand exports per day. Unless tied to a citation, every number is a stated design assumption.
Key Highlights
- •The browser is a compositor over proxies, never a transcoder of source media.
- •The timeline is a versioned declarative document; rendering is a compile step from that document.
- •Interactive plane wants latency and tolerates approximation; render plane wants throughput and exactness.
- •Four planes: ingest/storage, editing document, preview pipeline, render farm.
- •Every uncited scale number in this answer is an explicit design assumption, labeled where used.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate the interactive preview plane from the exact render plane before choosing any storage or compute."
- "The interesting constraint is not editing operations per second; it is moving and transforming terabytes of media per day."