Design Video Storage System

Hard45 min
1 / 30
understanding6 min read

Video Storage Context and Platform Goals

How Video Storage Context and Platform Goals (understanding) informs Video Storage System architecture and interviewer depth.

Video Storage Context and Platform Goals

Frame petabyte video storage as a durability-first bytes plane plus a queryable metadata catalog—distinct from upload, transcode, and CDN playback.

Problem framing
  • YouTube stores mezzanine separately from packaged HLS; Netflix optimizes for origin pull during peak primetime; AWS S3 Glacier Deep Archive targets compliance archives with hour-scale restore.
  • Companies like YouTube, Netflix, and AWS ask this to test bytes-vs-metadata thinking, not generic CRUD APIs.
  • Section 1 anchors the narrative before APIs and shard math.
Design choices
  1. Keep catalog strongly consistent; move bytes asynchronously across hot, warm, and cold pools.
  2. Content-hash keys with version lineage; never mutate mezzanine bytes in place.
  3. Credential broker issues object-scoped pre-signed URLs—no bucket admin keys on clients.
  4. Lifecycle driven by age, access heat, and contract tier with explicit transition metrics.
Deep dive

Walk through failure modes relevant here: degraded erasure shard, restore backlog, catalog replica lag, orphan multipart, and legal hold blocking GC. Mention reconciliation jobs proving catalog pointers match physical inventory.

javaOne Dark Pro
1// sec-001 — storage domain types
2public record BlobPointer(String assetId, int version, String pool, String contentHash, long byteSize) {}
3public enum StorageClass { HOT, WARM, COLD }
pythonOne Dark Pro
1# sec-001 — tier transition guard
2from enum import Enum
3
4class StorageClass(Enum):
5 HOT = "hot"
6 WARM = "warm"
7 COLD = "cold"
8
9def can_transition(current: StorageClass, target: StorageClass, legal_hold: bool) -> bool:
10 return not legal_hold and current != target
typescriptOne Dark Pro
1// sec-001 — signed read contract
2export interface BlobPointer {
3 assetId: string;
4 version: number;
5 pool: "hot" | "warm" | "cold";
6 contentHash: string;
7 byteSize: number;
8}
9
10export function signedGetUrl(ptr: BlobPointer, region: string, ttlSec: number): string {
11 return `https://${region}.origin.example/v1/blobs/${ptr.assetId}/v/${ptr.version}?ttl=${ttlSec}`;
12}
Interviewer positioning

Section 1 must cite measurable SLOs (hot p95 GET, restore p99, $/GB-month) and explicit boundaries with upload, transcode, and CDN—avoid vague scalability claims.

Operational notes
  • Runbook: spike 403 on signed GET → rotate broker signing keys.
Scale reference
  • Restore queue SLA: 10k jobs/hour/worker; 1 workers baseline.

Why interviewers care

Video Storage System interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Video Storage Context and Platform Goals that proves you understand real outages, not happy-path diagrams.

Key Highlights

  • Split catalog metadata from immutable content-addressed blobs
  • Catalog metadata never stores multi-GB payloads inline
  • Tier transitions are async jobs with rate limits and metrics
Interview Tip
Lead Video Storage Context and Platform Goals with numbers: ingest TB/day, hot p95, blended $/GB-month.
What Impresses
YouTube stores mezzanine separately from packaged HLS; Netflix optimizes for origin pull during peak primetime; AWS S3 Glacier Deep Archive targets compliance archives with hour-scale restore.
Avoid This
Do not put mezzanine bytes in SQL or skip orphan MPU / inventory reconciliation stories.

Section Rescue Kit

Buzzwords to use:

Erasure codingStorage class

Safe statements:

  • "I will separate catalog rows from multi-hundred-megabyte blobs before naming vendors."
  • "Let me quantify daily ingest terabytes and blended storage cost next."
Design Video Storage System - System Design | WinJob | WinJob