Video Streaming — CDN + Async Transcode (HLS + CloudFront)

The CDN + async transcode approach to video streaming represents the industry-standard architecture used by production VOD platforms at YouTube, Netflix, and Hulu scale. It solves the three fatal problems with the naive architecture: API-proxied uploads, synchronous transcoding, and origin-only delivery.

The first key insight is presigned URL upload. Instead of proxying video bytes through the API server (consuming gigabytes of memory per upload), the server generates a presigned S3 URL in 2ms and returns it to the client. The client uploads directly to S3 using multipart upload — splitting a 10GB file into 100MB chunks. If a chunk fails (mobile network drops), only that chunk is retried, not the entire upload. The API server never touches video bytes, eliminating the bandwidth and memory bottleneck entirely. At 6,000 uploads per second, the API server's work is signing 6,000 URLs — trivial compared to proxying 6,000 concurrent multi-gigabyte files.

The second key insight is async transcoding via Kafka. When the client signals upload completion, VideoService publishes a transcode-job event to a Kafka topic. The upload response returns immediately — the creator sees 'Video uploaded, processing...' in seconds, not after a 30-minute wait. TranscodeWorker pods consume jobs from Kafka and run FFmpeg to produce 5 HLS quality tiers: 240p (0.5 Mbps), 480p (1.5 Mbps), 720p (3 Mbps), 1080p (5 Mbps), and 4K (15 Mbps). Each tier is split into 10-second .ts segments with per-variant .m3u8 playlists and a master manifest. Transcoding takes 5-30 minutes but happens entirely in the background on dedicated workers — the API server's threads are never blocked.

The third key insight is CDN-first delivery. CloudFront serves all viewer traffic — HLS manifests, video segments, and thumbnails — from 400+ global edge locations. At a 95% cache hit rate, only 5% of requests reach the S3 origin. This transforms the egress equation: 100M concurrent viewers at 5 Mbps average = 500 Tbps total. Without CDN, all 500 Tbps hits S3 origin (impossible). With CDN at 95% cache hit, S3 sees only 25 Tbps of origin traffic, with 475 Tbps served from edge (feasible). CDN egress costs $0.01-0.02/GB versus S3's $0.09/GB — a 5-9x cost reduction that dominates the total cost of ownership.

The architecture separates read and write paths. VideoService handles the write path: upload initiation (presigned URL generation), upload completion (Kafka publishing), and user interactions (likes, comments). CatalogService handles the read path: video metadata queries with Redis caching at 90% hit rate. This separation allows independent scaling — CatalogService runs 10 pods for high read throughput while VideoService runs 4 pods for lower write volume.

HLS adaptive bitrate streaming is the viewer-facing improvement. Instead of a single 1080p MP4 that buffers on slow connections, the player fetches a master manifest listing all quality tiers with their bandwidth requirements. It selects an initial tier based on estimated bandwidth and fetches 10-second segments sequentially. If download speed drops (mobile entering a tunnel), the player switches to a lower tier (1080p to 720p to 480p) on the next segment boundary — maintaining smooth playback at reduced quality rather than buffering. If bandwidth improves, it switches up. This adaptive logic happens entirely in the client and is the reason every production video platform uses HLS or DASH.

Interviewers expect candidates to explain presigned URL upload and why the API server should never proxy video bytes, describe the async transcoding pipeline (Kafka + workers), justify CDN as the primary delivery mechanism with cost analysis, and discuss HLS adaptive bitrate as the solution to heterogeneous network conditions.

The CDN + async transcode architecture uses ten components organized into four layers: traffic ingestion (ViewerClient, UploaderClient, ApiGateway, MainLB), application services (VideoService, CatalogService), data stores (VideoDB/PostgreSQL, CatalogCache/Redis, VideoStore/S3), async pipeline (TranscodeStream/Kafka, TranscodeWorker), and edge delivery (CDN/CloudFront).

The upload path handles creator traffic — 5% of total requests but the most architecturally complex flow. UploaderClient sends POST /api/v1/videos/upload-init to VideoService via ApiGateway and MainLB. VideoService creates a video record in VideoDB (status=uploading), generates presigned S3 URLs for multipart upload (100MB chunks for a 10GB file = 100 URLs), and returns them to the client in approximately 50ms. The client uploads chunks directly to S3 — the API server never touches video bytes. After all chunks are uploaded, the client calls POST /api/v1/videos/{id}/upload-complete. VideoService publishes a transcode-job event to TranscodeStream (Kafka) and returns immediately. The upload flow completes in seconds.

The transcoding pipeline runs entirely in the background. TranscodeWorker pods (8 workers with 8 vCPU each) consume transcode-job events from Kafka. Each worker downloads the raw video from S3, runs FFmpeg to produce 5 HLS quality tiers (240p, 480p, 720p, 1080p, 4K), splits each tier into 10-second .ts segments, generates per-variant .m3u8 playlists and a master .m3u8 manifest, extracts a thumbnail image, and uploads all outputs to S3. Finally, it updates VideoDB with manifest_url and status=ready. Transcoding takes 5-30 minutes depending on video length and source resolution. Kafka's 7-day retention enables job replay on worker failure.

The playback path handles viewer traffic — 95% of total requests. ViewerClient fetches the master manifest from CDN (cache hit in 5ms). The HLS player parses the manifest, selects a quality tier based on bandwidth, and begins fetching .ts segments from CDN. CloudFront caches segments at edge locations with a 95% cache hit rate. Popular trending videos have near-100% hit rates because segments are immutable (once transcoded, they never change). Adaptive bitrate logic in the player monitors download speed per segment and switches tiers as needed.

The catalog browse path routes through ApiGateway, MainLB, and CatalogService. CatalogService checks CatalogCache (Redis, 90% hit rate) for video metadata (title, description, view count, manifest URL, thumbnail URL). On cache miss, it queries VideoDB (PostgreSQL). The response includes the CDN manifest URL that the player uses to start HLS playback.

Horizontal scaling is independent per component. CatalogService scales for read throughput (10 pods). VideoService scales for upload volume (4 pods). TranscodeWorker scales for transcoding backlog (8 workers). Kafka scales via partition count (8 partitions). CloudFront scales automatically with no configuration. Redis and PostgreSQL scale vertically within their instance class.

Auto-scaling per component: CatalogService scales on CPU utilization (target 60%, add pods at 70%). VideoService scales on request rate. TranscodeWorker scales on Kafka consumer lag (add workers when lag exceeds 500 jobs). Redis: vertical scaling within the r7g family (large to xlarge to 2xlarge). PostgreSQL: vertical scaling + read replicas for catalog query offload. CDN: automatic, no configuration. The architecture supports 100M+ concurrent viewers with proportional scaling of CDN capacity and origin infrastructure.

Key metrics: (1) CDN cache hit rate — the primary performance indicator. Alert below 90%, critical below 80%. (2) Kafka consumer lag on transcode-jobs — indicates transcoding backlog. Alert if lag exceeds 1,000 jobs (approximately 30 minutes of backlog). (3) Playback start latency (p99) — measured from manifest fetch to first segment rendered. Alert above 2 seconds. (4) Upload initiation latency (p99) — presigned URL generation should be under 100ms. Alert above 500ms. (5) Redis cache hit rate — alert below 85%. (6) TranscodeWorker processing time per video — baseline 5-30 minutes. Alert if mean exceeds 45 minutes (indicates resource contention). (7) S3 origin 5xx error rate — alert above 0.1%. Indicates throttling or service degradation.

At 10M concurrent viewers: CloudFront CDN egress (~$15,000/month at 500 Tbps with reserved capacity), TranscodeWorker 8 pods ECS Fargate 8vCPU ($2,500/month), VideoService 4 pods ($400/month), CatalogService 10 pods ($1,000/month), PostgreSQL db.r7g.xlarge ($350/month), Redis cache.r7g.large ($250/month), MSK Kafka 3 brokers ($600/month), S3 storage ~100TB ($2,300/month). Total: ~$22,400/month. Contrast with the naive variant: 1,000 viewers cost $146K/month in S3 egress alone. The CDN variant serves 10,000x more viewers at 1/6th the cost. CDN egress optimization (reserved capacity pricing, origin shield) can reduce the CDN bill by another 30-40%.

Presigned URL security: URLs are signed with AWS SigV4 and expire after 1 hour. Each URL is scoped to a specific S3 key — uploaders cannot overwrite other videos. CDN signed URLs for playback restrict access to authenticated viewers (optional — public videos skip signing). Content moderation: after transcoding completes, a moderation pipeline (out of scope) scans thumbnails and sample frames for policy violations before setting status=ready. Rate limiting: upload initiation limited to 10/minute per user to prevent storage abuse. API Gateway JWT authentication on all API endpoints.

Rolling deployment for VideoService and CatalogService — replace one pod at a time while the LB routes to healthy pods. TranscodeWorker: rolling replacement with Kafka consumer rebalancing. In-flight transcoding jobs on the old worker are lost but redelivered by Kafka. CDN: no deployment needed — CloudFront propagates configuration changes to all edge locations in 5-15 minutes. Database migrations during low-traffic windows with RDS blue/green deployment for zero-downtime schema changes.