aioff.
中文
Product design
PRODUCT DESIGN·7 min

Descript: collect recordings, then edit video like a document

Descript is a creation tool for editing audio and video through text. Podcasters and content teams can collect footage, change the order of a story, and deliver the finished work for others to watch.

Break down the problem and try your own design and implementation first. Then explore the reasoning to check states, edge cases, trade-offs, and ways to test your approach. The guide offers a reasoning path, not a complete implementation.

01
CODE EXERCISEAdvanced

Keep published exports from moving backward

Implement a teaching export-state module in any language, without connecting to a real video service. A snapshot is the fixed draft submitted for export; later edits do not change it.

  1. Inputs and outputs. Inputs are Edit, StartExport, ExportSucceeded and ExportFailed events. Export events have a unique jobId; success includes the frozen version and artifact URL. Outputs are the working version, each job's state, the public version and public URL. Versions are increasing positive integers.
  2. Publishing rules. Multiple exports may run in parallel. A success may publish only its own frozen version; an older success arriving late must not move the public version backward. Failure leaves the public pointer unchanged. Repeated callbacks for one jobId must be idempotent: receiving them again does not change the result again. Contradictory terminal callbacks report a conflict instead of replacing a terminal state.
  3. Small example. Start J1 at draft v=7, edit to v=8 and start J2. J2 succeeds first, followed by J1. Write the public version after each event. Also consider J2 failing while J1 succeeds: an older job must not be discarded merely because it started earlier.
  4. Scope. Artifacts are immutable. Do not implement uploads, page comments or permission services. The public pointer only moves forward. Starting a job must check that jobId is not used for another snapshot; a callback version must match the job record.
  5. Deliverables. Provide a data model, transitions and error types. Trace both examples plus duplicate success, failure followed by success, a forged version and the absence of an initial public version. State the expected public version and why.
Explore the reasoning
  1. Keep the working draft, job snapshot and public pointer separate. First identify which object an Edit changes.
  2. Use J2 succeeding first to find the no-regression invariant. Then use J2 failing to test whether accepting only the most recently started job would wrongly discard a usable result.
  3. Validate identity and version before deciding whether success advances the pointer. Unknown jobs and mismatched versions cannot publish.
  4. Give each job one terminal state. Distinguish identical replay from contradictory callbacks. Failure does not move the pointer, but should leave a diagnostic record.
  5. Test no initial publication, reordering, duplicates and failure with event traces. Do not infer a real product's backend implementation from this teaching protocol.