Design a platform where users upload videos that are processed into multiple resolutions and streamed to viewers worldwide with adaptive bitrate, plus view counts and recommendations at a basic level.

• Uploads: 500 h/min = 30k h/day. Raw ~1 GB/h → 30 TB/day raw; transcoded ladder (5 renditions) ≈ 3× → ~100 TB/day of stored video → ~36 PB/year.
• Views: 1B h/day at ~3 Mbps avg ≈ 1B × 3600 × 3 Mb ≈ 1.35 EB/day egress; that is why CDN and codec efficiency (VP9/AV1) matter more than any single server.
• Transcoding: ~1 CPU-hour per hour of video per rendition → 30k × 5 = 150k CPU-hours/day → ~6k always-on cores or GPU encoders.

POST /v1/videos/upload/init   { filename, size, mime } → { uploadId, presignedParts[] }
PUT  <presigned part url>     (client uploads chunks directly to object storage)
POST /v1/videos/upload/complete { uploadId, etags[] }  → { videoId, status:"processing" }
GET  /v1/videos/{id}           → metadata + { manifestUrl: "https://cdn/.../master.m3u8" }
GET  /v1/videos/{id}/status
POST /v1/videos/{id}/view      (beacon; batched client-side)

videos     (video_id, owner_id, title, description, status, duration, created_at)
renditions (video_id, resolution, codec, bitrate, manifest_path, size)
thumbnails (video_id, path)
view_events → Kafka → aggregated daily/hourly counts in an OLAP store
comments   (video_id, comment_id, user_id, text, ts)  -- separate service
Object storage: raw/{videoId}/source.mp4, hls/{videoId}/{rendition}/segment_N.ts + playlists

1. Upload: client gets presigned multipart URLs and uploads chunks straight to object storage (S3); resumable by part. Upload service records completion and enqueues a processing job.
2. Processing pipeline (DAG): split source into GOP-aligned chunks → transcode each chunk to each rendition in parallel (thousands of workers) → stitch → package to HLS/DASH segments (2–6 s) → thumbnails, captions, content moderation → write manifests → mark video ready.
3. Delivery: manifests and segments served through a multi-CDN; origin is object storage with an origin shield. Adaptive bitrate is client-driven: the player measures throughput and picks the rendition per segment.
4. Metadata service backed by a relational DB with read replicas; heavy caching.
5. View counting: players send beacons; Kafka → stream processor → approximate counts (HyperLogLog for unique viewers) → displayed counts updated every few seconds.
6. Search & recommendations: metadata indexed in Elasticsearch; recs from a separate ML pipeline.

Chunked parallel transcoding turns a 2-hour job into minutes; chunk on keyframe boundaries so chunks encode independently.

Adaptive bitrate: server produces the ladder (e.g. 240p→1080p/4K); the client's ABR algorithm (buffer-based or throughput-based) switches per segment. Short segments = faster start and adaptation; longer = better compression.

CDN strategy: popular content (top 1%) is pre-warmed to edge; long-tail served from origin shield. Cache key = segment path; immutable, long TTL.

Cost: cold-tier storage for videos with no views in 90 days; re-encode to a newer codec on demand.

• Transcode worker failure: chunks are idempotent tasks; retry with a visibility timeout; a job with a persistently failing chunk is flagged for manual review.
• CDN outage: multi-CDN with DNS/manifest-level steering; player retries the alternate CDN URL.
• Object storage regional outage: cross-region replication for manifests and hot renditions; raw uploads replicated asynchronously.
• Counter pipeline lag: display counts marked approximate; no impact on playback.