Bird
Raised Fist0

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

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
RTMP Ingest Servers

Receive live RTMP stream

Accept RTMP packets from broadcaster client

Protocol:RTMP
BeforeBroadcaster is connected but no stream data received
AfterRTMP stream packets buffered and ready for transcoding
Transcoder Cluster

Transcode RTMP to HLS segments

Convert live RTMP stream into multiple bitrate HLS TS segments

Protocol:Internal streaming
BeforeRaw RTMP packets buffered at transcoder
AfterHLS segments generated and queued for storage
Segment Store (Obj Storage)

Store HLS segments

Persist HLS TS segments and playlists for CDN retrieval

Protocol:HTTP PUT
BeforeHLS segments generated but not yet stored
AfterSegments durably stored and accessible via HTTP
Content Delivery Network (CDN)

Serve HLS segments to viewers

Cache and deliver HLS playlists and TS segments on viewer requests

Protocol:HTTP GET
BeforeSegments stored but not yet delivered to viewers
AfterViewers receive low-latency HLS stream segments
Stream Metadata & Chat Service

Update stream metadata and relay chat messages

Maintain live stream status and broadcast chat messages to viewers

Protocol:WebSocket / REST
BeforeStream metadata stale, chat messages queued at client
AfterMetadata updated and chat messages delivered in real-time
Monitoring & Alerting System

Monitor pipeline health

Collect metrics and trigger alerts on ingest or transcoding failures

Protocol:Metrics API
BeforeNo alerts active, metrics streaming from components
AfterAlerts triggered if latency or errors exceed thresholds
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   RTMP Ingest Servers  │
└─────────────┬─────────┘
              │ RTMP
              ▼
┌───────────────────────┐
│    Transcoder Cluster  │
└─────────────┬─────────┘
              │ HLS Segments (TS)
              ▼
┌───────────────────────────────┐
│   Segment Store (Obj Storage) │
└─────────────┬─────────────────┘
              │ HTTP PUT
              ▼
┌───────────────────────────────┐
│ Content Delivery Network (CDN)│
└─────────────┬─────────────────┘
              │ HTTP GET (HLS)
              ▼
          [ Viewers ]

┌───────────────────────────────┐
│ Stream Metadata & Chat Service │
└─────────────┬─────────────────┘
              │ WebSocket / REST
              ▼
┌───────────────────────────────┐
│ Monitoring & Alerting System   │
└───────────────────────────────┘
Design Rationale

This architecture shows a vertical flow from RTMP ingest to viewer delivery via HLS. The RTMP Ingest Servers accept live streams, forwarding them to the Transcoder Cluster which converts RTMP packets into HLS segments. These segments are stored durably in the Segment Store, an object storage system, enabling the CDN to efficiently cache and deliver content to viewers with low latency. Parallel to the media pipeline, the Stream Metadata & Chat Service manages live stream state and real-time chat, communicating with clients over WebSocket or REST. The Monitoring & Alerting System continuously tracks component health and triggers alerts on failures or latency spikes, ensuring reliability. This design balances low latency delivery with scalability and fault tolerance.

Primary Focus

✓

Practice

(1/5)
1. A web application needs a cache that automatically removes entries after a fixed time regardless of access frequency. Which cache eviction policy best fits this requirement?
easy
A. Least Frequently Used (LFU) eviction, which removes items accessed least often
B. Least Recently Used (LRU) eviction, which removes the oldest accessed items first
C. Time-To-Live (TTL) eviction, which expires entries after a set duration
D. Adaptive Replacement Cache (ARC), which balances recency and frequency

Solution

  1. Step 1: Identify eviction based on time expiration

    TTL eviction removes cache entries strictly after a fixed time, independent of access patterns.

  2. Step 2: Eliminate other policies

    LRU and LFU depend on access recency or frequency, not fixed time. ARC adapts between recency and frequency but does not enforce fixed expiration.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    TTL evicts by fixed time, ignoring usage patterns [check]
Hint: TTL evicts by time, not usage frequency or recency [OK]
Common Mistakes:
2. In a primary-replica replication system, at step 4 the replica receives a batch of write-ahead log entries from the primary. What is the replica's exact state after applying these entries?
easy
A. Replica marks entries as committed and acknowledges primary before applying
B. Replica applies entries to its data store and then acknowledges primary
C. Replica applies entries and immediately serves reads from them before acknowledgment
D. Replica buffers entries without applying until primary confirms commit

Solution

  1. Step 1: Trace replica behavior at step 4

    Replica applies WAL entries to its local store to catch up with primary.

  2. Step 2: Understand acknowledgment timing

    Replica acknowledges primary only after applying entries to ensure durability and consistency.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Replica applies then acknowledges -> ensures data durability [check]
Hint: Apply WAL entries before ack -> durability ensured [check]
Common Mistakes:
3. In a server-side service discovery flow, at step 4 the API Gateway queries the service registry for available instances. What happens if the registry returns stale data at this step?
easy
A. The API Gateway routes requests to possibly unavailable instances causing failures
B. The API Gateway caches the stale data but marks instances as unhealthy
C. The API Gateway falls back to client-side discovery automatically
D. The API Gateway retries the request until fresh data is received

Solution

  1. Step 1: Trace API Gateway behavior at step 4

    The API Gateway relies on the registry response to route requests; stale data leads to routing to unavailable instances.

  2. Step 2: Eliminate other options

    The API Gateway retries the request until fresh data is received is incorrect as retries are not automatic; The API Gateway falls back to client-side discovery automatically is false since fallback is not built-in; The API Gateway caches the stale data but marks instances as unhealthy is incorrect because caching stale data without health checks causes failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    API Gateway routes based on stale registry data causing failures [check]
Hint: Stale registry data routes to dead instances causing failures [OK]
Common Mistakes:
4. For a distributed counter requiring strong eventual consistency and minimal coordination, which architecture is best suited?
medium
A. Use sharded CRDT counters replicated asynchronously with conflict-free merges
B. Use a centralized counter service with distributed locks to serialize increments
C. Use a distributed database with linearizable transactions for each increment
D. Use a message queue with exactly-once delivery and synchronous aggregation

Solution

  1. Step 1: Evaluate coordination and consistency trade-offs

    Centralized locks (A) and linearizable transactions (C) impose coordination and reduce availability. Message queues with synchronous aggregation (D) add latency and bottlenecks.

  2. Step 2: Recognize sharded CRDT counters provide eventual consistency with no coordination

    They allow concurrent increments and asynchronous merges, fitting minimal coordination and strong eventual consistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Sharded CRDTs enable coordination-free eventual consistency [check]
Hint: CRDTs avoid coordination, unlike locks or linearizable DBs [check]
Common Mistakes:
5. For an API gateway that must limit requests to a steady rate and avoid sudden bursts, which rate limiting approach is best and why?
medium
A. Token bucket, because it allows bursts up to token capacity
B. Sliding window log, because it tracks exact timestamps but allows burst spikes
C. Leaky bucket, because it enforces a fixed output rate smoothing bursts
D. Fixed window counter, because it resets counts periodically allowing bursts

Solution

  1. Step 1: Analyze burst handling requirements

    The system must avoid sudden bursts and enforce steady rate.

  2. Step 2: Compare algorithms

    Token bucket allows bursts, fixed window counters reset counts causing bursts, sliding window logs allow spikes due to timestamp granularity.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Leaky bucket enforces steady output rate, smoothing bursts [check]
Hint: Leaky bucket smooths bursts; token bucket allows bursts [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