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
45 min · senior
senior

You are building a live streaming platform for a startup with 50 million daily active users. The platform ingests live video streams via RTMP from broadcasters and delivers them to viewers using HLS. The system must support low latency (P99 < 200ms), end-to-end encryption, and offline playback capabilities. The platform should scale to millions of concurrent viewers and thousands of concurrent streams. The business requires strict DRM compliance and seamless failover for broadcasters.

Constraints
  • End-to-end encryption from broadcaster to viewer with DRM support
  • P99 latency under 200ms from RTMP ingestion to HLS segment availability
  • Support offline playback with encrypted HLS segments cached on CDN
  • Scale to 50M DAU with up to 2M concurrent viewers and 10K concurrent streams
  • Seamless failover for RTMP ingest with minimal stream disruption
📋
Guided Steps
1/5
Step 1
RTMP Ingestion and Stream Authentication
How would you design the RTMP ingestion layer to authenticate broadcasters and ingest live streams reliably at scale?
💡 Hint
Consider using a scalable RTMP server cluster with token-based authentication and load balancing.
Key Decision
Use NGINX RTMP module with JWT token authentication and AWS Application Load Balancer for horizontal scaling and secure ingest.
Interviewer Expectation
Mid-level: Names NGINX RTMP and token auth. Senior: Explains JWT token expiry, ALB sticky sessions for stream affinity, and horizontal scaling limits of RTMP servers.
⚠️Common Wrong Answer
Using a single RTMP server without load balancing leads to a single point of failure and poor scalability.
Step 2
Low-Latency Transcoding and Packaging
How will you transcode RTMP streams to HLS segments ensuring P99 latency under 200ms?
💡 Hint
Look into chunked CMAF packaging and hardware-accelerated transcoding pipelines.
Key Decision
Use AWS Elemental MediaLive with chunked CMAF output and GPU-accelerated FFmpeg for real-time transcoding and packaging.
Interviewer Expectation
Mid-level: Mentions MediaLive or FFmpeg for transcoding. Senior: Details chunked CMAF reduces segment size and latency, GPU acceleration for real-time processing, and trade-offs with segment duration.
⚠️Common Wrong Answer
Using standard HLS with 10s segments causes >10s latency, violating the 200ms P99 latency requirement.
Step 3
Encrypted HLS Delivery and DRM Integration
How will you implement end-to-end encryption and DRM for HLS delivery to viewers?
💡 Hint
Consider AES-128 encryption for HLS segments and integration with Widevine or FairPlay DRM via a license server.
Key Decision
Use AWS CloudFront signed URLs with AES-128 encrypted HLS segments and integrate with AWS DRM (e.g., AWS MediaPackage DRM) for license management.
Interviewer Expectation
Mid-level: Names AES-128 encryption and signed URLs. Senior: Explains key rotation, license server scaling, and how DRM enforces playback restrictions on client devices.
⚠️Common Wrong Answer
Delivering unencrypted HLS segments exposes content to piracy and violates business DRM requirements.
Step 4
Scaling and CDN Caching for Offline Playback
How will you scale delivery to millions of viewers and support offline playback with encrypted cached segments?
💡 Hint
Use a global CDN with edge caching and support for encrypted segment storage and retrieval.
Key Decision
Use AWS CloudFront with Lambda@Edge to serve encrypted HLS segments cached globally, enabling offline playback with DRM enforcement.
Interviewer Expectation
Mid-level: Mentions CDN caching for scalability. Senior: Explains Lambda@Edge for token validation at edge, cache invalidation strategies, and offline playback DRM enforcement.
⚠️Common Wrong Answer
Serving all requests from origin causes high latency and origin overload, breaking scale and latency SLAs.
Step 5
Stream Health Monitoring and Failover
How will you monitor stream health and implement failover to minimize disruption during RTMP ingest failures?
💡 Hint
Implement heartbeat and stream quality metrics with automatic failover to backup ingest endpoints.
Key Decision
Use Prometheus exporters on RTMP servers for stream metrics, Grafana dashboards for monitoring, and Route 53 DNS failover with health checks for RTMP ingest failover.
Interviewer Expectation
Mid-level: Names Prometheus and health checks. Senior: Details metrics collected (bitrate, latency, packet loss), alerting thresholds, and DNS failover TTL tuning to minimize downtime.
⚠️Common Wrong Answer
No failover or manual failover causes prolonged stream outages and poor user experience.
🔌
API Design Challenge
Sketch 3 core API endpoints for the live streaming platform: broadcaster stream start, viewer stream playback, and stream health monitoring.
Hints
  • How does the broadcaster initiate and authenticate the RTMP stream?
  • How does the viewer request and receive the HLS playlist and segments?
  • How does the system expose stream health and latency metrics for monitoring?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Secure RTMP ingestion with token-based authentication and load balancing
  • Low-latency transcoding pipeline using chunked CMAF and hardware acceleration
  • Encrypted HLS delivery integrated with DRM license management
  • Global CDN caching with offline playback support and encrypted segment delivery
Good to Have - 30%
  • Comprehensive stream health monitoring with Prometheus and Grafana
  • Automated failover for RTMP ingest using DNS health checks
  • Token validation at CDN edge using Lambda@Edge to reduce origin load
Bonus - 10%
  • Detailed latency budget breakdown and capacity estimation for 50M DAU scale
  • Discussion of key rotation and DRM license server scaling strategies
Anti-patterns to Avoid
Single RTMP server without load balancing causes single point of failure and poor scalability, leading to stream outages under load
Using standard 10s HLS segments leads to >10s latency, violating low-latency requirements and degrading user experience
Delivering unencrypted HLS segments exposes content to piracy and violates DRM compliance, risking legal and business consequences
Serving all viewer requests from origin without CDN causes high latency and origin overload, breaking scale and latency SLAs
No stream health monitoring or failover leads to prolonged outages and poor user experience, damaging platform reliability
Polling-based health checks instead of event-driven monitoring increases latency and resource usage, reducing failover responsiveness
✅
Model Answer
▼ Reveal

The system uses NGINX RTMP with JWT authentication for secure ingest, AWS Elemental MediaLive with chunked CMAF for low-latency transcoding, and AWS CloudFront with Lambda@Edge for encrypted HLS delivery and offline playback. Prometheus and Grafana monitor stream health with Route 53 DNS failover for RTMP ingest.

Key Decisions
  • Use JWT tokens with short expiry and refresh to secure RTMP ingest and prevent replay attacks
  • Adopt chunked CMAF packaging to reduce HLS segment size to sub-second chunks, achieving P99 latency under 200ms
  • Leverage GPU acceleration in FFmpeg transcoding to meet real-time processing demands at scale
  • Encrypt HLS segments with AES-128 and enforce DRM policies via AWS MediaPackage license server
  • Deploy Lambda@Edge to validate viewer tokens at CDN edge, reducing origin load and enforcing DRM globally
  • Implement Prometheus and Grafana for detailed stream health metrics including bitrate, latency, and packet loss
  • Configure Route 53 DNS failover with tuned TTLs and health checks to minimize stream disruption during RTMP ingest failures
  • NGINX RTMP module with JWT token authentication for secure, scalable RTMP ingest
  • AWS Elemental MediaLive with chunked CMAF and GPU-accelerated FFmpeg for sub-200ms latency transcoding
  • AES-128 encrypted HLS segments delivered via AWS CloudFront signed URLs with AWS MediaPackage DRM integration
  • AWS CloudFront CDN with Lambda@Edge for encrypted segment caching and offline playback support
  • Prometheus and Grafana for real-time stream health monitoring with Route 53 DNS failover for RTMP ingest
  • Use of chunked CMAF reduces HLS segment size from typical 6-10s to sub-second chunks enabling low latency
  • JWT tokens with short expiry and refresh mechanism prevent unauthorized stream ingestion and replay attacks
  • Lambda@Edge validates viewer tokens at CDN edge, reducing origin load and enforcing DRM policies globally

Practice

(1/5)
1. A webhook delivery system must guarantee ordered delivery of events per subscriber, even under retries and failures. Which component is best suited to enforce per-subscriber ordering?
easy
A. A partitioned message queue like Kafka keyed by subscriber ID
B. A distributed cache like Redis to store last delivered event per subscriber
C. A relational database with a global sequence number column
D. A load balancer that routes events to the same delivery worker

Solution

  1. Step 1: Identify ordering guarantee mechanism

    Kafka partitions keyed by subscriber ID ensure all events for that subscriber go to the same partition, preserving order.

  2. Step 2: Eliminate other options

    Redis cache lacks strong ordering guarantees under retries; relational DB global sequence causes contention and latency; load balancer routing alone doesn't guarantee ordering without stateful processing.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka partition key -> per-subscriber ordering guaranteed [check]
Hint: Partition by subscriber ID for ordering [check]
Common Mistakes:
2. A distributed file system must handle frequent small file metadata updates with low latency. Which component is primarily responsible for managing these metadata operations efficiently?
easy
A. Data Nodes storing actual file blocks and handling read/write requests
B. Client-side caching to reduce metadata server load
C. Metadata Servers maintaining namespace hierarchy and file metadata
D. Load balancers distributing client requests evenly across data nodes

Solution

  1. Step 1: Identify Metadata Server role

    Metadata Servers maintain the namespace and metadata such as file attributes and directory structure, handling frequent metadata updates.

  2. Step 2: Eliminate other components

    Data Nodes store file blocks but do not manage metadata; client caching reduces load but does not handle updates; load balancers distribute traffic but don't manage metadata.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Metadata Servers handle namespace and metadata updates efficiently [check]
Hint: Metadata Servers manage namespace and metadata updates [check]
Common Mistakes:
3. A critical database cluster must failover automatically without data loss or downtime during a primary node crash. Which component is responsible for orchestrating this failover in a distributed SQL database system?
easy
A. Consensus protocol (e.g., Raft) managing leader election and log replication
B. Load balancer redirecting traffic based on health checks
C. Client-side retry logic to reconnect to a new primary node
D. Backup scheduler triggering periodic snapshots for recovery

Solution

  1. Step 1: Identify failover orchestration component

    The consensus protocol like Raft manages leader election and ensures log replication consistency, enabling automatic failover without data loss.

  2. Step 2: Eliminate other options

    Client-side retries (A) handle reconnection but don't orchestrate failover; load balancers (B) redirect traffic but don't manage state; backups (D) aid recovery but not live failover.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Consensus protocol controls leader election and failover [check]
Hint: Consensus protocols manage failover, not clients or load balancers
Common Mistakes:
4. A messaging system must decouple high-throughput message producers from multiple independent consumers subscribing to different topics. Which component best handles this decoupling and ensures message durability?
easy
A. Use a distributed log-based system like Kafka with topic partitions
B. Use a simple in-memory queue on the producer server to buffer messages
C. Use a direct HTTP push from producer to each consumer
D. Use a relational database with polling by consumers

Solution

  1. Step 1: Identify decoupling and durability needs

    In-memory queues (Use a simple in-memory queue on the producer server to buffer messages) lack durability and don't scale across servers. Direct HTTP push (Use a direct HTTP push from producer to each consumer) tightly couples producer and consumers, causing backpressure issues. Polling a relational DB (Use a relational database with polling by consumers) adds latency and load on DB, unsuitable for high throughput.

  2. Step 2: Recognize Kafka's role

    Kafka's distributed log with topic partitions decouples producers and consumers, provides durability, and supports high throughput with consumer groups.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka partitions enable durable, scalable decoupling [check]
Hint: Distributed logs decouple producers and consumers reliably [OK]
Common Mistakes:
5. If the metadata server in a file storage system crashes, what exactly breaks in the file write operation?
medium
A. File data blocks are lost permanently because they were never written to disk.
B. The system automatically switches to object storage to handle writes.
C. Clients can continue writing files normally without any impact.
D. Clients can write data blocks, but file metadata updates are lost, causing inconsistent directory state.

Solution

  1. Step 1: Understand metadata server role in file writes

    The metadata server manages file metadata; if it crashes, metadata updates are lost but data blocks may be written.

  2. Step 2: Trace failure impact

    Without metadata updates, directory entries and inode info become inconsistent, leading to orphaned or inaccessible files despite data blocks existing.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Metadata server crash -> lost metadata, inconsistent directory [check]
Hint: Metadata server down -> metadata lost, data blocks orphaned [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