Live Streaming (Instagram Live/YouTube Live)

0Problem RestatementProblem

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.

1RequirementsRequirements

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

• Storage: Record streams for replay (1 hour stream × 3 Mbps = 1.35 GB).

1.4 API Design

The core APIs required for the service:

2High-Level ArchitectureArchitecture

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

%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart TB
    %% Broadcaster
    Broadcaster["Broadcaster<br/>(Mobile/Desktop)"] -->|"1. RTMP/WebRTC Stream"| Ingestion["Ingestion Service<br/>(RTMP/WebRTC)"]
    
    %% Video Processing
    Ingestion -->|"2. Raw Video Stream"| Transcoder["Live Transcoder<br/>(Multiple Resolutions)"]
    Transcoder -->|"3. 360p, 720p, 1080p"| Packager["Packager<br/>(HLS/DASH)"]
    
    %% Origin and CDN
    Packager -->|"4. HLS Segments"| Origin["Origin Server"]
    Origin -->|"5. Distribute"| CDN["CDN<br/>(CloudFront/Akamai)"]
    
    %% Viewers
    CDN -->|"6. Video Stream"| Viewer1["Viewer 1"]
    CDN -->|"6. Video Stream"| Viewer2["Viewer 2"]
    CDN -->|"6. Video Stream"| ViewerN["Viewer N"]
    
    %% Chat and Interactions
    Viewer1 -->|"7. Send Message"| ChatWS["Chat WebSocket<br/>Server"]
    Viewer2 -->|"7. Send Message"| ChatWS
    ViewerN -->|"7. Send Message"| ChatWS
    
    ChatWS -->|"8. Broadcast Message"| Viewer1
    ChatWS -->|"8. Broadcast Message"| Viewer2
    ChatWS -->|"8. Broadcast Message"| ViewerN
    
    ChatWS -->|"9. Persist Messages"| ChatDB[(Chat DB)]
    
    %% Viewer Count
    Viewer1 -->|"10. Heartbeat"| ViewerTrack["Viewer Tracking"]
    Viewer2 -->|"10. Heartbeat"| ViewerTrack
    ViewerN -->|"10. Heartbeat"| ViewerTrack
    ViewerTrack -->|"11. Update Count"| Redis["Redis<br/>(Live Count)"]
    
    %% Recording
    Origin -->|"15. Save Stream"| Recorder["Recording Service"]
    Recorder -->|"16. Store Video"| S3["Object Storage<br/>(S3)"]
    
    %% Notifications
    Broadcaster -->|"12. Go Live Event"| NotifQueue["Notification Queue"]
    NotifQueue -->|"13. Consume"| NotifService["Notification Service"]
    NotifService -->|"14. Notify Followers"| Followers["Followers"]
    
    %% Styling
    classDef broadcaster fill:#e3f2fd,stroke:#1976d2,stroke-width:2px;
    classDef video fill:#c8e6c9,stroke:#388e3c,stroke-width:2px;
    classDef cdn fill:#ffe0b2,stroke:#e65100,stroke-width:2px;
    classDef interaction fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px;
    
    class Broadcaster broadcaster;
    class Ingestion,Transcoder,Packager,Origin,Recorder video;
    class CDN,Viewer1,Viewer2,ViewerN cdn;
    class ChatWS,ViewerTrack,Redis,ChatDB,NotifQueue,NotifService interaction;

3Components (what & why)

Broadcaster (Client)

• Mobile app or desktop software (OBS, Streamlabs).
• Capture video/audio from camera and microphone.
• Encode and send stream to ingestion server via RTMP or WebRTC.

Ingestion Service

• Accept live video streams from broadcasters.
• Protocols: RTMP (traditional), WebRTC (low-latency).
• Load Balancing: Route to nearest ingestion server.
• Validation: Check broadcaster authentication, stream key.

Live Transcoder

• Responsibilities:
• Transcode incoming stream to multiple resolutions (360p, 720p, 1080p).
• Encode with H.264 or H.265 codec.
• Generate adaptive bitrate ladder.
• Real-Time: Process with minimal delay (< 2 seconds).
• Scaling: Spin up transcoders on-demand per stream — but only for streams that need it. Most of 100K concurrent streams have a handful of viewers; for those, pass the source through at one quality (no transcoding) and start the full bitrate ladder once viewership crosses a threshold. Transcoding is the biggest compute cost in the system.

Packager

• Convert transcoded streams to HLS (HTTP Live Streaming) or DASH format.
• Generate manifest files (.m3u8 for HLS).
• Create video segments (e.g., 2-second chunks).

Origin Server

• Store live stream segments temporarily (e.g., last 30 seconds).
• Serve as source for CDN.
• Low Latency: Use low-latency HLS (LL-HLS) or CMAF.

CDN (Content Delivery Network)

• Distribute video segments to viewers globally.
• Cache segments at edge locations.
• Scaling: Auto-scale to millions of viewers.

Chat WebSocket Server

• Real-time bidirectional communication for chat.
• Broadcast messages to all viewers in stream.
• Scaling: Shard by stream_id, use multiple servers.
• Protocol: WebSocket for low latency.

Chat DB

• Persist chat messages for replay.
• DB Choice: Cassandra (time-series) or MongoDB.

Viewer Tracking

• Track active viewers per stream.
• Implementation: Viewers send heartbeat every 5 seconds.
• Storage: Redis for real-time count.
• Display: Show live count to all viewers.

Recording Service

• Capture live stream segments and save to object storage.
• Post-Processing: Stitch segments into full video for replay.
• Storage: S3 with lifecycle policies (archive after 30 days).

Notification Service

• Notify followers when broadcaster goes live.
• Channels: Push notifications, in-app alerts.
• Async: Use message queue to fan-out notifications.

4Data ModelData model

Stream

Stream(
  stream_id,
  broadcaster_id,
  title,
  status,  -- LIVE, ENDED
  start_time,
  end_time,
  viewer_count_peak,
  recording_url
)

Chat Message

ChatMessage(
  message_id,
  stream_id,
  user_id,
  message_text,
  timestamp
)

Viewer Session

ViewerSession(
  session_id,
  stream_id,
  viewer_id,
  joined_at,
  left_at,
  watch_duration_seconds
)

Stream Segment (Temporary)

{
  "stream_id": "live123",
  "segment_number": 42,
  "url": "https://cdn.example.com/live123/720p/segment-042.ts",
  "duration": 2.0,
  "created_at": "2023-10-20T10:05:24Z"
}

5Key FlowsFlows

5.1 Start Live Stream Flow

1. Broadcaster taps "Go Live" in app.
2. App requests stream key from backend.
3. Backend creates Stream record with status LIVE.
4. Notification Service fans out "User X is live" to followers.
5. Broadcaster's app starts streaming via RTMP to Ingestion Service.
6. Ingestion routes stream to Transcoder.
7. Transcoder generates multiple resolutions and sends to Packager.
8. Packager creates HLS segments and manifest.
9. Origin server receives segments.
10. CDN pulls and caches segments.

5.2 Watch Live Stream Flow

1. Viewer taps on live stream thumbnail.
2. App requests stream manifest URL from backend.
3. Backend returns HLS manifest URL (CDN link).
4. Video player fetches manifest and starts downloading segments.
5. Player adapts quality based on bandwidth (ABR).
6. Viewer sends heartbeat every 5 seconds for viewer count.
7. Viewer joins chat WebSocket channel for stream.

5.3 Send Chat Message Flow

1. Viewer types message and sends.
2. Message sent to Chat WebSocket Server.
3. Server validates message (rate limit, profanity filter).
4. Server broadcasts message to all viewers in stream.
5. Server persists message to Chat DB (async).

5.4 End Live Stream Flow

1. Broadcaster taps "End Stream".
2. App stops sending video, sends end signal.
3. Ingestion Service marks stream as ENDED.
4. Origin flushes final segments to CDN.
5. Recording Service stitches segments into full video.
6. Full video uploaded to S3.
7. Stream record updated with recording_url.

5.5 Replay Flow

1. User views past live stream.
2. App requests recording_url from backend.
3. Backend returns VOD (Video on Demand) URL from CDN.
4. Standard video player loads and plays recorded stream.

6Deep Dive A: Low-Latency Video Delivery (~10 mins)Deep dive

Problem

Traditional HLS has 10-30 seconds latency (buffering segments). For live streaming, we need < 5 seconds glass-to-glass latency.

Latency Breakdown (Traditional HLS)

Total: 20-30 seconds
├─ Encoding: 2-3 seconds
├─ Segmentation: 6 seconds (3 × 2-second segments buffered)
├─ CDN propagation: 2 seconds
├─ Client buffering: 6 seconds (3 segments)
└─ Network jitter: 3-5 seconds

Solution: Low-Latency HLS (LL-HLS)

Chunked Transfer Encoding

• Stream segments as they're generated (don't wait for full segment).
• Use HTTP chunked transfer to send partial data.
• Benefit: Reduce segment buffering time from 6s to 1s.

Smaller Segments

• Reduce segment size from 6 seconds to 1-2 seconds.
• Trade-off: More segments = more HTTP requests (mitigated by HTTP/2).

Partial Segments

• Send segment in chunks (e.g., 0.5-second chunks within 2-second segment).
• Player starts playing before full segment received.

Prefetch Hints

• Manifest includes hints about upcoming segments.
• Player pre-fetches next segment while playing current.

Alternative: WebRTC

Ultra-Low Latency

• WebRTC achieves sub-second latency (< 500ms).
• Use Case: Interactive streams (gaming, auctions).

Trade-offs

• More complex infrastructure (STUN/TURN servers).
• Every viewer needs a live connection to a media server (an SFU) instead of fetching cacheable HTTP segments, so standard CDNs can't absorb the load and cost per viewer is much higher.
• Scalability challenges (peer-to-peer not feasible for millions).

Latency Comparison

Traditional HLS:  20-30 seconds
Low-Latency HLS:  3-5 seconds
WebRTC:           < 1 second

Low-Latency HLS Architecture

%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart LR
    Broadcaster["Broadcaster"] -->|"RTMP"| Encoder["Real-Time Encoder<br/>(1-2s delay)"]
    Encoder -->|"small segments (1s)"| Packager["LL-HLS Packager"]
    
    Packager -->|"chunked transfer"| Origin["Origin Server"]
    Origin -->|"prefetch hints"| CDN["CDN Edge"]
    
    CDN -->|"adaptive stream"| Player["Video Player<br/>(ABR)"]
    
    classDef live fill:#c8e6c9,stroke:#388e3c,stroke-width:2px;
    classDef delivery fill:#ffe0b2,stroke:#e65100,stroke-width:2px;
    
    class Encoder,Packager live;
    class Origin,CDN,Player delivery;

7Deep Dive B: Adaptive Bitrate Streaming (~8 mins)Deep dive

Problem

Viewers have varying network speeds (3G to fiber). Fixed bitrate causes buffering for slow connections or poor quality for fast connections.

Solution: Adaptive Bitrate Streaming (ABR)

Bitrate Ladder

• Encode stream at multiple resolutions and bitrates:
• 360p @ 1 Mbps (low bandwidth)
• 480p @ 2 Mbps
• 720p @ 3 Mbps (HD)
• 1080p @ 6 Mbps (Full HD)

Player-Side Adaptation

• Video player monitors:
• Download speed: Measure segment download time.
• Buffer health: Seconds of video buffered.
• Decision:
• If buffer draining → switch to lower quality.
• If buffer healthy + fast download → switch to higher quality.

HLS Manifest (Master Playlist)

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
https://cdn.example.com/stream/360p/playlist.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=3000000,RESOLUTION=1280x720
https://cdn.example.com/stream/720p/playlist.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=6000000,RESOLUTION=1920x1080
https://cdn.example.com/stream/1080p/playlist.m3u8

Segment Playlist (720p)

#EXTM3U
#EXT-X-TARGETDURATION:2
#EXTINF:2.0,
segment-001.ts
#EXTINF:2.0,
segment-002.ts
#EXTINF:2.0,
segment-003.ts

ABR Algorithm (Simplified)

if buffer_level < 2 seconds:
    switch_to_lower_quality()
elif buffer_level > 10 seconds and download_speed > 2x current_bitrate:
    switch_to_higher_quality()

Transcoding Pipeline

%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart TD
    Input["Input Stream<br/>(1080p source)"] --> Transcoder["Live Transcoder"]
    
    Transcoder --> R360["360p Encoder<br/>(1 Mbps)"]
    Transcoder --> R720["720p Encoder<br/>(3 Mbps)"]
    Transcoder --> R1080["1080p Encoder<br/>(6 Mbps)"]
    
    R360 --> Seg360["Segmenter"]
    R720 --> Seg720["Segmenter"]
    R1080 --> Seg1080["Segmenter"]
    
    Seg360 --> Origin["Origin Server<br/>(HLS Master Playlist)"]
    Seg720 --> Origin
    Seg1080 --> Origin
    
    classDef transcode fill:#c8e6c9,stroke:#388e3c,stroke-width:2px;
    
    class Transcoder,R360,R720,R1080 transcode;

8Deep Dive C: Real-Time Chat & Interactions (~7 mins)Deep dive

Problem

Handle thousands of chat messages per second for popular streams with minimal latency.

WebSocket Architecture

Connection Management

• Each viewer opens WebSocket connection to Chat Server.
• Sharding: Partition connections by stream_id.
• Stream A → Chat Server 1, 2, 3.
• Stream B → Chat Server 4, 5, 6.
• Load Balancing: Distribute connections evenly.

Message Flow

1. Viewer sends message via WebSocket.
2. Server validates (rate limit: 5 messages/min per user).
3. Server publishes message to pub/sub (Redis Pub/Sub).
4. All Chat Servers subscribed to stream_id channel receive message.
5. Each server broadcasts to its connected viewers.

Pub/Sub Pattern (Redis)

Publisher (Chat Server 1) → Redis Channel "stream:123"
                               ↓
              ┌────────────────┼────────────────┐
              ↓                ↓                ↓
   Chat Server 1    Chat Server 2    Chat Server 3
       ↓                 ↓                 ↓
  Viewers 1-10K    Viewers 10K-20K   Viewers 20K-30K

Message Persistence

• Async worker persists messages to Chat DB.
• Write Optimization: Batch insert (e.g., 100 messages every 1 second).

Rate Limiting

• Prevent spam: Limit to 5 messages/min per user.
• Implementation: Token bucket in Redis.
• Penalty: Temporary mute (1 minute) for violations.

Chat at 1M Viewers

Naive broadcast breaks at scale: 10K messages/sec × 1M viewers = 10 billion deliveries/sec, and no human can read 10K messages/sec anyway.

• Sample what each viewer sees: deliver at most ~20–50 messages/sec per viewer (a random or ranked subset), always including messages from the broadcaster, moderators, and people the viewer follows. Everyone can still post; not everyone sees every message.
• Batch: send one frame every ~200ms holding several messages instead of one frame per message.
• Slow mode: for huge streams, raise the per-user limit (e.g. one message every 30s) and require followers-only chat if needed.
• Tree fan-out: publish once to a regional relay, which fans out to its chat servers, which fan out to their connections — no single node sends to all 1M.

Reactions (Hearts, Emojis)

• Lightweight events (no persistence needed for most reactions).
• Aggregate counts in memory (e.g., 1500 hearts in last 5 seconds).
• Broadcast aggregated count to viewers.

Chat Architecture

%%{init: {"look":"handDrawn","handDrawnSeed":7,"theme":"base","fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","themeVariables":{"fontFamily":"Virgil, \"Segoe Print\", \"Comic Sans MS\", cursive","fontSize":"16px","primaryColor":"#fff4e6","primaryBorderColor":"#1e1e1e","primaryTextColor":"#1e1e1e","secondaryColor":"#e7f5ff","tertiaryColor":"#ebfbee","lineColor":"#1e1e1e","textColor":"#1e1e1e","mainBkg":"#fff4e6","nodeBorder":"#1e1e1e","clusterBkg":"#f8f9fa","edgeLabelBackground":"#ffffff","classText":"#1e1e1e"}}}%%
flowchart TD
    V1["Viewer 1"] -->|"WebSocket"| WS1["Chat Server 1"]
    V2["Viewer 2"] -->|"WebSocket"| WS1
    V3["Viewer 3"] -->|"WebSocket"| WS2["Chat Server 2"]
    V4["Viewer 4"] -->|"WebSocket"| WS2
    
    WS1 -->|"publish message"| Redis["Redis Pub/Sub<br/>(stream:123)"]
    WS2 -->|"publish message"| Redis
    
    Redis -->|"subscribe"| WS1
    Redis -->|"subscribe"| WS2
    
    WS1 -->|"broadcast"| V1
    WS1 -->|"broadcast"| V2
    WS2 -->|"broadcast"| V3
    WS2 -->|"broadcast"| V4
    
    WS1 -->|"persist (async)"| ChatDB[(Chat DB)]
    WS2 -->|"persist (async)"| ChatDB
    
    classDef ws fill:#c8e6c9,stroke:#388e3c,stroke-width:2px;
    classDef viewer fill:#e3f2fd,stroke:#1976d2,stroke-width:2px;
    
    class WS1,WS2 ws;
    class V1,V2,V3,V4 viewer;

9Scaling & Performance (~5 mins)Scale

Horizontal Scaling

• Ingestion: Multiple ingestion servers per region.
• Transcoders: Auto-scale based on streams that need a bitrate ladder (small streams pass through the source quality only).
• Chat Servers: Auto-scale based on total WebSocket connections.
• CDN: Automatically scales with viewer demand.

Performance Metrics

• Glass-to-glass latency: < 5 seconds (LL-HLS).
• Chat latency: < 500ms (WebSocket).
• Concurrent viewers: 1M+ per stream (CDN).
• Stream quality: Adaptive 360p-1080p.

Cost Optimization

• Transcoding: Use hardware encoders (GPU) for efficiency.
• CDN: Cache aggressively, use tiered pricing.
• Storage: Archive old recordings to cheaper storage (Glacier).

10Failure Modes & Recovery

Broadcaster Disconnect

• Detection: Ingestion server sees the connection drop without an explicit "end stream" signal.
• Action: Flush buffered segments to the CDN and start the grace-period timer.
• Recovery: Keep the stream in a RECONNECTING state for a grace period (e.g. 60–90 seconds): viewers stay on the same stream and see a "reconnecting" slate, and the broadcaster's app reconnects with the same stream key and stream_id. Only mark it ENDED if the grace period runs out.

Transcoder Failure

• Impact: Stream stops.
• Mitigation: Spin up backup transcoder, resume from last segment.

CDN Edge Failure

• Impact: Viewers in region can't watch.
• Mitigation: CDN automatically routes to next nearest edge.

Chat Server Failure

• Impact: Some viewers lose chat connection.
• Mitigation: Reconnect WebSocket, catch up on missed messages.

11Trade-offs & AlternativesTrade-offs

HLS vs DASH

• HLS: Better iOS/Safari support, simpler.
• DASH: More flexible, open standard.
• Choice: HLS (wider adoption).

Low-Latency HLS vs WebRTC

• LL-HLS: 3-5s latency, scalable, works with CDN.
• WebRTC: Sub-second latency, complex, limited scale.
• Choice: LL-HLS for most use cases, WebRTC for ultra-low-latency needs.

Live vs Pre-Recorded

• Live: Real-time engagement, interactive.
• Pre-Recorded: Better quality, no latency concerns.
• Instagram/YouTube: Support both.

12Security & Privacy

Stream Authentication

• Generate unique stream key per broadcaster.
• Validate key before accepting stream.

Viewer Authentication

• Require login to watch (private streams).
• Token-based access for paid streams.

Content Moderation

• AI-powered detection of inappropriate content (real-time).
• Chat moderation (profanity filters).

DRM

• For premium content, use DRM (FairPlay, Widevine).

13Interview Time Allocation (45 min)

• 5 min: Requirements & scope (functional, non-functional, scale).
• 10 min: HLD & architecture diagram (broadcast + interaction pipelines).
• 5 min: Data model & key flows (start stream, watch, chat).
• 10 min: Deep dive on low-latency video delivery (LL-HLS vs WebRTC).
• 8 min: Deep dive on adaptive bitrate streaming (ABR algorithm).
• 5 min: Real-time chat, scaling, failure handling.
• 2 min: Trade-offs, security, wrap-up.

14SummaryWrap-up

• Core Challenges: Low-latency video delivery (< 5s), adaptive streaming for varying bandwidth, real-time chat for millions, scaling to massive viewer counts.
• Key Components:
• Ingestion: RTMP/WebRTC from broadcaster.
• Transcoding: Real-time encoding to multiple resolutions.
• Packaging: HLS segments with low-latency optimizations.
• CDN: Global distribution with edge caching.
• Chat: WebSocket + Redis Pub/Sub for real-time messaging.
• Scaling Strategy: Horizontal scaling of all services, CDN auto-scaling, sharded chat servers.
• Performance: 3-5s glass-to-glass latency, 1M+ concurrent viewers, adaptive 360p-1080p quality.

This design powers live streaming platforms serving millions of concurrent viewers with low latency and interactive features.