CASE STUDY

Live Streaming (Instagram Live/YouTube Live)

405 words·Beginner

How to use this case study

SDE-2 / Mid

Study the full Live Streaming (Instagram Live/YouTube Live) case study. Focus on understanding the core components and how they interact. Focus on sections 1-3: requirements, API design, and high-level architecture. Understand the RTMP ingest, transcoding pipeline, and adaptive bitrate streaming.

SDE-3 / Senior

Study the full Live Streaming (Instagram Live/YouTube Live) case study. Focus on understanding the core components and how they interact. Be ready to discuss the chat system design (WebSocket vs SSE), how to handle broadcaster disconnects, and the CDN edge caching strategy for live content.

Staff / Principal

Study the full Live Streaming (Instagram Live/YouTube Live) case study. Focus on understanding the core components and how they interact. Be prepared to discuss the global CDN topology for <5s latency, how to handle 1M+ concurrent viewers on a single stream, and the trade-offs between HLS and DASH for low-latency delivery. Discuss cost optimization for transcoding.

# Live Streaming (Instagram Live/YouTube Live)\

\

---\

\

0) Problem Restatement\

Design a live streaming platform like Instagram Live or YouTube Live where users can broadcast live video to thousands/millions of viewers with minimal latency. Core challenges include real-time video ingestion, adaptive bitrate streaming for varying network conditions, low-latency delivery (< 5 seconds), interactive features (chat, reactions), and scaling to millions of concurrent viewers.\

\


1) Requirements\

\

1.1 Functional\

  • Start/stop live stream: Broadcasters can start and end live streams.\
  • Watch live stream: Viewers can watch live streams in real-time.\
  • Adaptive quality: Automatically adjust video quality based on viewer's bandwidth.\
  • Live chat: Viewers can send messages during live stream.\
  • Reactions: Viewers can send emojis/reactions in real-time.\
  • Viewer count: Display live viewer count.\
  • Notifications: Notify followers when user goes live.\
  • Record and replay: Save live stream for replay after it ends.\
  • Discovery: Browse live streams (trending, following, explore).\
\

1.2 Non-Functional\

  • Low Latency: < 5 seconds from broadcaster to viewer (glass-to-glass).\
  • Scalability: Support millions of concurrent viewers for popular streams.\
  • Availability: 99.9% uptime.\
  • Quality: Adaptive streaming (360p to 1080p).\
  • Reliability: Handle broadcaster disconnects, viewer drops.\
  • Cost Efficiency: Optimize CDN and transcoding costs.\
\

1.3 Scale Estimates\

  • Concurrent streams: 100K live streams at any time.\
  • Avg viewers per stream: 100-1000 viewers.\
  • Peak stream: 1M viewers (major events, celebrities).\
  • Latency target: 3-5 seconds (low-latency HLS or WebRTC).\
  • Bitrates: 360p (1 Mbps), 720p (3 Mbps), 1080p (6 Mbps).\
  • Chat messages: 10K messages/sec for popular stream.\
  • Storage: Record streams for replay (1 hour stream × 3 Mbps = 1.35 GB).\
\

1.4 API Design\

The core APIs required for the service:\

  • Start Stream: POST /v1/stream/start - Init stream, get stream key.\
  • End Stream: POST /v1/stream/end - Stop recording, close session.\
  • Get Manifest: GET /v1/stream/:id/manifest - Get HLS/DASH URL.\
  • Post Message: POST /v1/stream/:id/chat - Send chat message.\
  • Add Reaction: POST /v1/stream/:id/reaction - Send heart/emoji.\
\

---\

\

2) High-Level Architecture\

\

2.1 Overview\

  • Broadcast Pipeline: Broadcaster → Ingestion → Transcoding → Origin → CDN → Viewers.\
  • Interaction Pipeline: Chat, reactions, viewer count via WebSocket.\
  • Key components: RTMP ingestion, real-time transcoding, CDN distribution, WebSocket for chat.\
\

2.2 Architecture Diagram\

```mermaid\

---\

config:\

layout: elk\

---\

flowchart TB\

%% Broadcaster\

Broadcaster[\

More Case Studies

Practice with a Mock Interview

Apply what you learned in a live system design mock interview with our AI interviewer.

Start System Design Interview →