sydepsystem design atlas

Live Streaming Platform

Ingest a live feed, transcode in near real time, and fan out to viewers at the edge.

AdvancedMedia
BroadcasterClientIngest EndpointEdge & IoTLive TranscoderAnalytics & DataStreaming CDNNetworkingViewerClientLive ChatMessaging

A broadcaster's stream is ingested, transcoded into multiple bitrates continuously, and distributed through the CDN with a real-time chat channel running alongside for viewer interaction.

When to use it

  • Content is broadcast live rather than uploaded ahead of time
  • Viewer interaction (chat, reactions) needs to happen alongside the stream in real time

Trade-offs

  • End-to-end latency (ingest -> transcode -> CDN -> viewer) is much harder to minimise than for VOD
  • Live infrastructure cannot gracefully degrade the way VOD can; a failure is visible immediately

Components used

Desktop AppEdge FunctionStream ProcessingCDNMobile AppEvent Bus

How it works

  • The broadcaster pushes a feed to an ingest endpoint, which transcodes it into multiple renditions in near real time rather than as a batch job.
  • Segments are published continuously to a CDN, and viewers pull them with a manifest that keeps refreshing.
  • Latency is a tunable trade-off: smaller segments reduce delay but increase request overhead and reduce buffering headroom.

Used in the wild

  • Live sports and event broadcasting.
  • Creator streaming platforms with chat interaction.
  • Webinars and virtual conferences.

Good to know

  • Standard HLS latency is typically 15–30 seconds, which is fine for a concert and unacceptable for live betting or interactive chat where viewers see spoilers before the video.
  • Unlike on-demand video, there is no second chance. A transcoding failure during a live event is simply lost, so redundant ingest paths are standard for anything important.