Bird
Raised Fist0

Design a Live Streaming Platform - Low-Latency RTMP to HLS Pipeline

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design a Live Streaming Platform - Low-Latency RTMP to HLS Pipeline
Design a scalable, low-latency live streaming platform converting RTMP streams to HLS for billions of users
hardVideo and Media StreamingFreq: high
Prerequisites:System Design FundamentalsCAP TheoremVideo Streaming Protocols (RTMP, HLS)Distributed SystemsContent Delivery Networks (CDN)
⚙️
Functional Requirements
  • Ingest live video streams from broadcasters via RTMP protocol
  • Transcode and segment streams into HLS format with low latency (<5s end-to-end)
  • Distribute HLS segments to viewers globally via CDN
  • Support live chat and metadata overlay synchronized with video
  • Allow stream recording and playback for up to 7 days
  • Provide stream health monitoring and alerting
📊
Non-Functional Requirements
  • Support 2 billion daily active users (DAU) with peak concurrent viewers of 50 million
  • End-to-end latency from broadcaster to viewer under 5 seconds (P99)
  • System availability of 99.99% uptime
  • Stream ingest write throughput of 925K RTMP messages per second
  • HLS segment delivery with 100ms P99 response time from CDN edge
❓
Clarifying Questions to Ask
  • What is the maximum allowed latency from RTMP ingest to HLS playback?
  • What is the expected average and peak concurrent viewers per stream?
  • Are we supporting adaptive bitrate streaming with multiple quality levels?
  • What is the retention period for recorded streams?
  • Is live chat tightly synchronized with video playback?
  • What geographic regions must be supported for low latency?
Out of Scope
✗ Design of video encoding algorithms (e.g., H.264, H.265)
✗ User authentication and authorization mechanisms
✗ Monetization and ad insertion
✗ Detailed CDN internal design
📌
Assumptions
  • 2 billion DAU
  • Each user watches 40 live stream segments per day
  • Average RTMP message size is 100 KB (video chunk + metadata)
  • Retention period for recorded streams is 7 days
⚡
QPS Calculation
write qps2B users × 40 segments/day ÷ 86400 seconds ≈ 925,926 RTMP messages/sec
peak write qpsAssuming 3× peak factor: 925,926 × 3 ≈ 2.78M RTMP messages/sec
read qpsAssuming 10× read amplification for viewers: 925,926 × 10 ≈ 9.26M HLS segment requests/sec
💾
Storage Estimate
daily storage2B × 40 × 100 KB = 8 PB/day
retention storage8 PB/day × 7 days = 56 PB
with replication56 PB × 3 (replication factor) = 168 PB total storage
🖥️
Server Estimate
ingest serversAssuming each RTMP ingest server handles 10K msg/sec, need 2.78M ÷ 10K = 278 ingest servers
transcoding serversAssuming each transcoder handles 100 concurrent streams, with 50M peak viewers and 1M concurrent streams, need 10K transcoding servers
🏗️
Architecture Diagram
Architecture Diagram
          +-------------+
          | Broadcaster |
          +------+------+
                 | RTMP Ingest
          +------+------+
          | RTMP Ingest |
          +------+------+
                 | Raw Stream
          +------+------+
          | Transcoder |
          +------+------+
                 | HLS Segments
          +------+------+
          | Segment Store|
          +------+------+
                 | CDN Push
          +------+------+
          | CDN Edge   |
          +------+------+
                 | HLS Playback
          +------+------+
          | Viewer     |
🧩
Components
RTMP Ingest Servers
Receive live RTMP streams from broadcasters, validate and forward raw video data
Why thisNginx RTMP module supports high-throughput RTMP ingest with built-in connection management and low latency
Why notApache HTTP Server lacks native RTMP support and would require complex plugins, increasing latency and reducing throughput
Transcoder Cluster
Convert raw RTMP streams into segmented HLS format with multiple bitrates for adaptive streaming
Why thisFFmpeg with GPU acceleration enables real-time transcoding at scale with low latency
Why notSoftware-only transcoding (e.g., x264 CPU-only) cannot meet latency and scale requirements due to CPU bottlenecks
Segment Store (Object Storage)
Store HLS segments durably and serve as origin for CDN
Why thisAmazon S3 or equivalent object storage provides high durability, scalability, and cost-effective storage for large volumes of video segments
Why notDistributed file systems like HDFS have higher latency and complexity, unsuitable for low-latency segment retrieval
Content Delivery Network (CDN)
Distribute HLS segments globally with low latency and high availability
Why thisCloudflare or Akamai CDN offers edge caching, HTTP/2 support, and global PoPs to reduce latency to viewers
Why notSelf-managed CDN requires massive infrastructure and cannot match global scale and latency SLAs
Stream Metadata & Chat Service
Manage live chat messages and metadata overlays synchronized with video playback
Why thisApache Kafka provides durable, ordered message streams with low latency for chat and metadata synchronization
Why notRedis Pub/Sub lacks persistence and ordering guarantees, risking message loss and inconsistency
Monitoring & Alerting System
Track stream health, latency, errors, and trigger alerts for operational issues
Why thisPrometheus with Grafana enables real-time metrics collection and visualization with alerting rules
Why notCloudWatch or other black-box monitoring lacks flexibility for custom live streaming metrics and alerting
🔄
Data Flow
1
Broadcaster → RTMP Ingest Servers
Send live video stream via RTMP protocol
RTMP ingest servers validate and accept incoming streams
2
RTMP Ingest Servers → Transcoder Cluster
Forward raw video stream for transcoding
Streams are load balanced across transcoder nodes
3
Transcoder Cluster → Segment Store
Store segmented HLS chunks and playlists
Segments are uploaded immediately after encoding
4
Segment Store → CDN Edge
Push or pull HLS segments for caching
CDN caches segments close to viewers for low latency
5
Viewer → CDN Edge
Request HLS segments for playback
CDN serves cached segments with <100ms latency
6
Stream Metadata & Chat Service → Viewer
Deliver synchronized chat and metadata messages
Kafka streams ensure ordered, durable delivery

Practice

(1/5)
1. A distributed messaging system processes millions of events per second. Some messages fail processing due to transient errors and must be retried without blocking the main queue. Which component best handles isolating these failed messages for later inspection and retry?
easy
A. A Dead Letter Queue (DLQ) configured to capture failed messages separately
B. A cache layer like Redis to temporarily store failed messages for retry
C. A high-throughput relational database with retry logic in application code
D. A load balancer that redirects failed messages to a backup server

Solution

  1. Step 1: Identify the role of Dead Letter Queues

    DLQs isolate failed messages from the main queue, enabling retries without blocking normal processing.

  2. Step 2: Evaluate alternatives

    Relational DBs (A) add latency and complexity; Redis (C) lacks durability guarantees; load balancers (D) do not handle message state or retries.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    DLQ isolates failures for retry without blocking main queue [check]
Hint: Dead Letter Queues isolate failures, not caches or DBs [OK]
Common Mistakes:
2. In a distributed counter system using sharded CRDTs, at Step 4 the Aggregator node merges shard states received from replicas. What is the Aggregator's state immediately after merging two shards with counts 100 and 150?
easy
A. The Aggregator state is the average of the two counts: 125, to smooth spikes
B. The Aggregator state is the maximum of the two counts: 150, to avoid double counting
C. The Aggregator state is the sum: 250, reflecting all increments
D. The Aggregator state resets to zero after merging to avoid stale data

Solution

  1. Step 1: Understand CRDT merge semantics for counters

    Sharded counters merge by summing counts from each shard to reflect total increments without double counting.

  2. Step 2: Apply merge to counts 100 and 150

    Sum is 250, representing combined increments from both shards.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    CRDT counters merge by summing shard values [check]
Hint: CRDT counters merge by summing shard counts [check]
Common Mistakes:
3. For storing feature metadata and versioning in the registry, which storage approach is best when the system requires strong consistency and auditability for compliance?
medium
A. Use a relational database with ACID transactions and audit logging
B. Use a cloud object store with versioned files and eventual consistency
C. Use a distributed log system like Kafka to append feature metadata changes
D. Use a distributed NoSQL store with eventual consistency and high availability

Solution

  1. Step 1: Identify compliance needs for strong consistency and auditability

    Compliance requires strict transactional guarantees and immutable audit trails.

  2. Step 2: Evaluate storage options

    NoSQL and object stores offer eventual consistency, risking stale reads. Kafka provides append-only logs but lacks transactional ACID guarantees for metadata queries. Relational DBs provide ACID transactions and built-in audit logging, ensuring compliance.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Relational DBs ensure ACID and audit logging for compliance [check]
Hint: Compliance needs ACID and audit logs -> relational DB [check]
Common Mistakes:
4. For the fraud detection system's rule engine, which architecture best supports rapid rule updates without downtime while maintaining low latency scoring?
medium
A. Embed rules directly in the scoring service code and redeploy on changes
B. Use an external rule engine service with hot-reloadable rule definitions
C. Store rules in a database and query them synchronously during scoring
D. Compile rules into scoring service binaries and load at startup only

Solution

  1. Step 1: Evaluate embedding rules in code (A) and binaries (D)

    Both require redeployment or restart on rule changes, causing downtime or latency spikes.

  2. Step 2: Assess querying rules synchronously (C)

    Querying rules synchronously adds latency and risk of inconsistent rule versions during scoring.

  3. Step 3: Consider external rule engine with hot-reload (B)

    This allows dynamic rule updates without downtime and low latency via caching and efficient evaluation.

  4. Final Answer:

    Option B -> Option B

  5. Quick Check:

    External hot-reload rule engine -> dynamic updates, low latency [check]
Hint: Hot-reload rule engine enables live updates without downtime [check]
Common Mistakes:
5. For a stock exchange system requiring low-latency order matching and high availability, which architecture is best suited to handle failover without losing in-flight orders?
medium
A. Use a distributed matching engine with partitioned order books per stock symbol and asynchronous replication
B. Use a single centralized matching engine with synchronous replication to a hot standby
C. Use multiple independent matching engines with eventual consistency and conflict resolution
D. Use a cloud-managed database with built-in failover and no dedicated matching engine

Solution

  1. Step 1: Analyze architecture requirements

    Low latency and high availability require partitioning to avoid bottlenecks and asynchronous replication to avoid blocking on failover.

  2. Step 2: Evaluate options

    Use a single centralized matching engine with synchronous replication to a hot standby blocks on synchronous replication causing latency; Use multiple independent matching engines with eventual consistency and conflict resolution risks conflicts and inconsistent order books; Use a cloud-managed database with built-in failover and no dedicated matching engine lacks dedicated matching engine causing latency and complexity.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Partitioned matching engine + async replication -> low latency + availability [check]
Hint: Partition and async replication for low latency failover [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard