System Design 4: Design OTT Platform like Netflix, Amazon Prime, Hotstar (HLD & LLD)

An Over-The-Top (OTT) video streaming platform delivers subscription-based media content directly to viewers over the internet. Designing such a system requires handling massive global concurrency, storing large video libraries, executing multi-bitrate video processing, and minimizing playback buffering using edge Content Delivery Networks (CDNs).

1. Why Do We Need This? (Problem Statement & Status Quo)

Traditional broadcasting relies on cable, satellite, or terrestrial airwaves with fixed bandwidth and scheduled programming. OTT platforms bypass traditional distribution intermediaries, allowing users to watch media on demand across diverse connected devices (smartphones, smart TVs, browsers, tablets).

However, delivering 4K and 1080p video streams to 200 million global users introduces significant engineering hurdles:

• Massive Bandwidth Demands: A single uncompressed 4K movie can exceed 40–100 GB. Streaming raw files directly over variable internet connections is physically impossible.
• Heterogeneous Client Devices: Users connect via erratic mobile networks (2 Mbps) and robust fiber connections (100+ Mbps). The system must dynamically adapt quality in real-time.
• Zero-Downtime Availability: Interruptions during movie playback destroy user experience, demanding an architecture that prioritizes high availability over strict data consistency.

2. Core Mental Model & Real-Life Analogies

Real-Life Analogy: The Postal Delivery of Fragmented Books

Imagine shipping an entire 1,000-page encyclopedia across the country. Shipping it as one heavy, bound book is expensive, slow, and prone to transit damage. Instead, the publisher breaks the encyclopedia down into 10-page pamphlets, ships them sequentially in smaller batches, and provides an index (manifest) telling the reader the exact order to read them. If a local post office box (CDN) keeps popular pamphlets right around the corner, delivery is instantaneous. If traffic slows down, the reader can temporarily request a smaller, summarized pamphlet (lower resolution) until normal delivery speed resumes.

3. Gathering Requirements (Functional & Non-Functional)

Functional Requirements

• User Account & Subscription: Users must register, log in, and purchase monthly or yearly subscription plans to access content.
• Search & Discovery: Users can search for movies and TV shows by title or genre.
• Multi-Resolution Playback: The platform must support video streaming ranging from standard definition (480p) up to 4K ultra-high definition.
• Out of Scope: Real-time recommendation engines (which require complex AI/ML pipelines) are excluded from this core design round.

Non-Functional Requirements

• Global Scale: Architected to support ~200 million active users worldwide with a catalog size of around 10,000 video titles (averaging 1 hour each). Note that users do not upload personal content (unlike YouTube).
• CAP Theorem Trade-off: We prioritize Availability (A) over Consistency (C) for the video streaming layer. If a new video is uploaded, a minor delay in propagating metadata globally is acceptable. However, payment and subscription modules require strict transactional reliability.
• Ultra-Low Latency & Zero Buffering: Seamless video playback with minimal startup delay and zero mid-stream stuttering.

4. Core Entities

Identifying the fundamental database entities required to support our functional workflows:

5. API Design

API endpoints map directly to our core functional requirements using RESTful conventions:

6. High-Level System Architecture

The high-level architecture separates user management, search indexing, and video storage behind an API Gateway and Load Balancer.

7. Low-Level Design & Deep Dive: Component Breakdown

A. User & Subscription Services (Transactional Consistency)

• Database Choice: Relational MySQL databases are used for both UserDB and SubscriptionDB to guarantee strict ACID compliance on billing and account states.
• Event-Driven Payment Pipeline:
  1. The user submits credit card info to the Payment Service.
  2. The external Payment Gateway processes the charge and returns an asynchronous webhook/acknowledgement.
  3. The event is published to an Apache Kafka broker.
  4. A Kafka consumer picks up the event, updates the UserDB expiration date, and triggers the Notification Server to email the user.

B. Search Service Optimization

• Scanning a relational database for title and genre searches is inefficient at scale.
• We implement Elasticsearch backed by a CDC (Change Data Capture) pipeline connected to the primary video database to sync search indexes in near real-time.

8. Low-Level Design: Video Processing & Streaming Pipeline

This is the most critical subsystem in an OTT platform. Raw video files cannot be streamed directly due to massive file sizes and variable network conditions.

How Video Chunking & Manifest Files Work

1. Chunking: A 2-hour movie is split by the Chunker Service into thousands of small, independent 6-to-10-second segments (also called keyframes or I-frames).
2. Encoding: The Video Encoder Service compresses each segment into multiple bitrates/resolutions (480p, 720p, 1080p, 4K).
3. Manifest Files: A manifest file (.m3u8 for HLS or .mpd for MPEG-DASH) acts as an index coordinating the exact sequence, timing, and URL paths of all encoded video segments.

9. Playback Flow & Adaptive Bitrate Streaming (ABR)

When a user clicks "Play", the client device dynamically evaluates network bandwidth in real-time to select the optimal video segment quality without buffering.

Caching Strategy with CDNs

To prevent high latency and repetitive hits on S3 blob storage, popular video segments are cached across geographically distributed Content Delivery Networks (CDNs) located close to regional users. If a requested chunk misses at the CDN edge, it fetches from S3 and caches it locally.

10. Streaming Protocols Comparison: HLS vs. MPEG-DASH

11. Summary and Key Takeaways

• High Availability Focus: OTT system design prioritizes high availability (AP in CAP Theorem) for video streaming over strict consistency.
• Separation of Concerns: Uncompressed source videos are handled exclusively by backend maintenance teams via dedicated uploaders, entirely separate from user playback flows.
• Microservices Architecture: The system cleanly decouples User Management, Subscription Billing, Search (Elasticsearch), and Playback services.
• Asynchronous Workflows: Payment processing and user notification updates rely on Kafka event brokers and CDC pipelines to decouple critical transaction paths.
• Video Chunking: Splitting hours-long video files into 6-10 second chunks allows seamless quality switching mid-stream.
• Adaptive Bitrate Streaming (ABR): Clients dynamically read manifest files (.m3u8 / .mpd) and adjust video resolution on the fly based on current network bandwidth.
• CDN Caching: Geographically distributed CDNs cache popular video chunks near end-users, dramatically reducing backend S3 load and eliminating buffering.
• Protocol Preference: MPEG-DASH is frequently preferred over HLS in modern enterprise OTT platforms due to superior chunk granularity and multi-bitrate prefetching capabilities.